ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
paulk-bis has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
djbw has joined #dri-devel
<jenatali> karolherbst: !19242 is ready for review if you wanted to take a look
<karolherbst> yep, will do so tomorrow I hope. After I'm done deleting like random driver code :3
<jekstrand> Ok, MSAA resolves implemented in Vulkan meta. :D
<jekstrand> Well, at least for color. IDK if my depth/stencil hacks work yet.
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
khfeng_ has quit [Ping timeout: 480 seconds]
ngcortes has quit [Quit: Leaving]
<jenatali> \o/
<jekstrand> Pass: 214644, Fail: 613, Crash: 418, Warn: 4, Skip: 1344758, Flake: 126, Duration: 14:25
<jekstrand> 99.4%
<jenatali> jekstrand: nice!
<jenatali> jekstrand: btw ping on that WSI change whenever you get a chance
<jenatali> I don't need something thorough yet, it's not fully done, but a "this seems okay" vs "omg start over" would be appreciated
<jekstrand> jenatali: Yeah. I've still got the tab open.
<jenatali> Thanks!
OftenTimeConsuming is now known as Guest4246
OftenTimeConsuming has joined #dri-devel
Guest4246 has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
* karolherbst wonders if iris should stop caring about clover once it's officially conformant with rusticl...
mbrost has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
<HdkR> karolherbst: Sounds reasonable to me
kem has joined #dri-devel
mbrost has joined #dri-devel
bmodem has joined #dri-devel
<jenatali> "PASSED 35 of 35 tests." \o/
<karolherbst> maybe I want to wire it up as well now
<jenatali> karolherbst: What's there should be enough for basic cl_khr_gl_sharing, to get cl_khr_gl_event's implicit CL -> GL sync to work I had to rely on some driver-private details
khfeng_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
pendingchaos has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
mhenning has quit [Quit: mhenning]
khfeng_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lanodan_ has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
lanodan_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
paulk has joined #dri-devel
reductum has quit [Remote host closed the connection]
reductum has joined #dri-devel
Company has quit [Quit: Leaving]
Duke`` has joined #dri-devel
bgs has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
fab has joined #dri-devel
rahul_janga has joined #dri-devel
bgs has quit [Remote host closed the connection]
kts has joined #dri-devel
danvet has joined #dri-devel
<Lynne> karolherbst: I'm trying to test !19232 (rusticl on radeonsi) on navi21, but I'm not seeing any devices under the platform, regardless of envvars
<Lynne> is that intended or is my hardware not supported yet?
mszyprow has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
jlawryno has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jewins1 has joined #dri-devel
<illwieckz> Lynne, maybe you have to set RUSTICL_ENABLE=radeonsi
fab has quit [Quit: fab]
jewins has quit [Ping timeout: 480 seconds]
<illwieckz> it is expected all radeonsi hardware are supported ( https://twitter.com/illwieckz/status/1582907160798773250/photo/1 ), so if it's not listed, either it's disabled, either there is a problem in the build/install
<dolphin> airlied, danvet: super busy week, will send the initial drm-intel-gt-next early next week, if you folks are able to pull it, I'll then need to backmerge drm-next to bring in some dependencies
mvlad has joined #dri-devel
rahul_janga has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
tzimmermann has joined #dri-devel
bbrezillon has joined #dri-devel
srslypascal has quit [Read error: No route to host]
srslypascal has joined #dri-devel
tursulin has joined #dri-devel
khfeng_ has joined #dri-devel
<Lynne> illwieckz: thanks, it was RUSTICL_ENABLE, not RUSTICL_DEVICE_ENABLE
<illwieckz> 👍️
fab has joined #dri-devel
<illwieckz> note that since functions are inlined for now, some large kernels may take so much time to compile it's like it never ends
<illwieckz> so make sure to have a proper way to kill an app you test
jewins1 has quit [Ping timeout: 480 seconds]
<danvet> dolphin, ok
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Lynne> why is rusticl implemented on top of opengl drivers though, doesn't it make more sense to implement on top of vulkan?
<illwieckz> it's not on top of opengl
<illwieckz> both opengl and rusticl are implemented on top of gallium
<illwieckz> and vulkan and gallium are basically side to side
rasterman has joined #dri-devel
<illwieckz> there are some wip patches by karolherbst that are also making rusticl works over vulkan, but vulkan doesn't expose every feature a gpu has, so for example rusticl over gallium may one day implement the extensions required by CHIP-SPV to do HIP over OpenCL, but rusticl over vulkan has no way to be compatible with CHIP-SPV because of vulkan not providing required features
<Lynne> right, I forgot radeonis is gallium
<Lynne> *radeonsi
<Lynne> hip on top of opencl -_-
<Lynne> I think all vulkan needs to be a good general purpose compute platform is a good set of libraries and a good glsl->spv compiler
<Lynne> glslang is bad enough that me and haasn considered ripping out the glsl -> nir -> spirv path mesa uses for zink into a separate library
ahajda_ has joined #dri-devel
vliaskov has joined #dri-devel
jkrzyszt has joined #dri-devel
khfeng_ has quit [Read error: Connection reset by peer]
khfeng_ has joined #dri-devel
<Lynne> yup, I actually tried running the rusticl zink branch first a week ago but ran into a different issue (no platforms available at all)
pcercuei has joined #dri-devel
lynxeye has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
tlwoerner_ has joined #dri-devel
flto_ has joined #dri-devel
warpme____ has joined #dri-devel
Moe_Icenowy has joined #dri-devel
mmx_in_orbit__ has joined #dri-devel
kathleen_ has joined #dri-devel
cheako_ has joined #dri-devel
dschuermann_ has joined #dri-devel
ezequielg_ has joined #dri-devel
steev_ has joined #dri-devel
gouchi has joined #dri-devel
arnd_ has joined #dri-devel
gouchi has quit []
ernstp___ has joined #dri-devel
Eschik_ has joined #dri-devel
reduz___ has joined #dri-devel
rib____ has joined #dri-devel
rodrigovivi_ has joined #dri-devel
seanpaul_ has joined #dri-devel
krushia_ has joined #dri-devel
krh_ has joined #dri-devel
dianders_ has joined #dri-devel
zf_ has joined #dri-devel
flibit has joined #dri-devel
reductum_ has joined #dri-devel
everfree_ has joined #dri-devel
djbw_ has joined #dri-devel
orbea1 has joined #dri-devel
reductum has quit [synthon.oftc.net larich.oftc.net]
djbw has quit [synthon.oftc.net larich.oftc.net]
dviola has quit [synthon.oftc.net larich.oftc.net]
flto has quit [synthon.oftc.net larich.oftc.net]
genpaku has quit [synthon.oftc.net larich.oftc.net]
warpme___ has quit [synthon.oftc.net larich.oftc.net]
orbea has quit [synthon.oftc.net larich.oftc.net]
zehortigoza has quit [synthon.oftc.net larich.oftc.net]
flibitijibibo has quit [synthon.oftc.net larich.oftc.net]
Lyude has quit [synthon.oftc.net larich.oftc.net]
zf has quit [synthon.oftc.net larich.oftc.net]
andrey-konovalov has quit [synthon.oftc.net larich.oftc.net]
krushia has quit [synthon.oftc.net larich.oftc.net]
mareko has quit [synthon.oftc.net larich.oftc.net]
jolan has quit [synthon.oftc.net larich.oftc.net]
cheako has quit [synthon.oftc.net larich.oftc.net]
technopoirot has quit [synthon.oftc.net larich.oftc.net]
clever has quit [synthon.oftc.net larich.oftc.net]
Eschik has quit [synthon.oftc.net larich.oftc.net]
dianders has quit [synthon.oftc.net larich.oftc.net]
arnd has quit [synthon.oftc.net larich.oftc.net]
steev has quit [synthon.oftc.net larich.oftc.net]
ernstp__ has quit [synthon.oftc.net larich.oftc.net]
dschuermann has quit [synthon.oftc.net larich.oftc.net]
reduz__ has quit [synthon.oftc.net larich.oftc.net]
seanpaul has quit [synthon.oftc.net larich.oftc.net]
mmx_in_orbit_ has quit [synthon.oftc.net larich.oftc.net]
olv has quit [synthon.oftc.net larich.oftc.net]
ezequielg has quit [synthon.oftc.net larich.oftc.net]
kathleen has quit [synthon.oftc.net larich.oftc.net]
MoeIcenowy has quit [synthon.oftc.net larich.oftc.net]
everfree has quit [synthon.oftc.net larich.oftc.net]
tlwoerner has quit [synthon.oftc.net larich.oftc.net]
rib___ has quit [synthon.oftc.net larich.oftc.net]
rodrigovivi has quit [synthon.oftc.net larich.oftc.net]
krh has quit [synthon.oftc.net larich.oftc.net]
steev_ is now known as steev
olv_ has joined #dri-devel
jolan has joined #dri-devel
dviola has joined #dri-devel
kem has joined #dri-devel
zehortigoza has joined #dri-devel
genpaku has joined #dri-devel
mareko has joined #dri-devel
clever has joined #dri-devel
andrey-konovalov has joined #dri-devel
ZeZu has quit [Read error: Connection reset by peer]
technopoirot has joined #dri-devel
ZeZu has joined #dri-devel
Lyude has joined #dri-devel
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest4330
bmodem has quit [Ping timeout: 480 seconds]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Akari has joined #dri-devel
kts has quit [Quit: Leaving]
pendingchaos has joined #dri-devel
apinheiro has joined #dri-devel
devilhorns has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
mrkajetanp has joined #dri-devel
<haasn> Lynne: what it needs is dynamic dispatch
<haasn> You currently cannot do everything OpenCL kernels can do in Vulkan
<haasn> And the restriction seems sort of artificial to me
jkrzyszt has quit [Remote host closed the connection]
<haasn> like literally that's the only relevant difference between the Kernel and Compute classes in SPIR-V or w/e they're called
<Lynne> wasn't there a spir-v extension for that?
<Lynne> or am I confusing it with the pointer extension
mrkajetanp has quit [Remote host closed the connection]
<haasn> there's an nvidia-specific extension to construct arbitrary command buffers
<haasn> but it's not really usable
<haasn> for one, too overengineered, for two, nvidia-only
itoral has quit [Remote host closed the connection]
<Lynne> VK_NV_device_generated_commands?
<haasn> that's the one
<Lynne> couldn't you somewhat make up for it with pipeline libraries extension?
<Lynne> you could precompile all combinations you think you might encounter and just bind a pipeline when you render
<Lynne> it's not proper arbitrary construction, but a compiled pipeline is what, a megabyte tops?
<haasn> you could do it with conditional execution and a fixed upper limit on the number of loops
<Lynne> probably the same overhead as the extension itself, but I do agree a proper extension would allow libraries to target a command buffer passed to them without needing multiple dispatches
<Lynne> didn't take that long for mesh shaders to go from nvidia only to a generic extension, for all we know, they're probably already working on a generic version
<Lynne> ...under top secrecy, very public
<airlied> haasn: structured vs unstructued flow control is also a big difference
kts has joined #dri-devel
dviola has joined #dri-devel
fab has quit [Quit: fab]
<haasn> airlied: what does that mean in this context? arbitrary goto?
<haasn> seems like it yeah
<haasn> > We found that the requirement for structured control flow can increase the number of registers allocated by 20 registers and impact performance as much as 2x.
<haasn> heh
vliaskov has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<jenatali> That sounds wrong but I don't know enough to dispute it
mbrost has joined #dri-devel
kts has quit [Quit: Leaving]
orbea1 has quit []
orbea has joined #dri-devel
kts has joined #dri-devel
heat has joined #dri-devel
pochu has quit [Quit: leaving]
mbrost has quit [Read error: Connection reset by peer]
rasterman has quit [Ping timeout: 480 seconds]
<jenatali> Oh sure, structurizing what was unstructured code can slow down performance, but if the content was authored structured I don't see why it would have to be worse
Akari has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
rgallaispou has joined #dri-devel
kkawg has joined #dri-devel
devilhorns has quit []
kts has quit [Quit: Leaving]
camus has quit []
flto_ has quit []
flto has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
jlawryno has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
gbelgurr has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
EricCurtin[m] has joined #dri-devel
kts has joined #dri-devel
jlawryno has joined #dri-devel
gbelgurr has joined #dri-devel
fxkamd has joined #dri-devel
jkrzyszt has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rodrigovivi_ is now known as rodrigovivi
tzimmermann has quit [Quit: Leaving]
rodrigovivi has quit []
rodrigovivi has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
flibit has quit []
flibitijibibo has joined #dri-devel
mszyprow has joined #dri-devel
stuart has joined #dri-devel
<jenatali> Hm, we should probably turn off the Windows runners for Amber CI
<jenatali> Nobody's going to use Amber for anything on Windows...
kem has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
kem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
swalker_ has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
swalker_ is now known as Guest4357
Guest4330 has quit [Remote host closed the connection]
jlawryno has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
Guest4357 has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<bbrezillon> danvet: I've been playing with dma_fence today, and I noticed something weird. Unlike dma_buf objects, dma_fences don't take an owner (struct module), so I wonder what happens if a fence created by a driver lasts longer than the driver itself (for instance, when some other driver still has a reference to this fence).
jkrzyszt has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
djbw_ has joined #dri-devel
cheako_ has quit []
cheako_ has joined #dri-devel
cheako_ has quit []
cheako has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
kts has quit [Quit: Leaving]
jljusten has quit [Quit: WeeChat 3.6]
jljusten has joined #dri-devel
<eric_engestrom> jenatali: sounds good; wanna MR that? ;P
<jenatali> eric_engestrom: Yeah. I'll get to it, hopefully today
<eric_engestrom> thx :)
<eric_engestrom> (I mean, no rush, I don't think anyone's doing anything with amber for now anyway)
Lucretia has quit [Read error: Connection reset by peer]
<jenatali> Yeah, I just realized yesterday after seeing your message about the Windows runner hanging
<jenatali> Instead of trying to fix/update it, we should just turn it off
<eric_engestrom> I mean, that works for this one, but the rest of the CI infra will need to be maintained
<jenatali> Yeah. It just gets me off the hook ;)
Lucretia has joined #dri-devel
<eric_engestrom> hehe
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
Akari has joined #dri-devel
<danvet> bbrezillon, the same thing that happens with a dma-buf
<danvet> well not quite
<danvet> the owner only protects against the module disappearing, not against the driver disappearing
<danvet> the long story is very, very sad
<danvet> you'll just oops eventually
<danvet> we should fix all this, but it's tricky and a mess
apinheiro has quit [Ping timeout: 480 seconds]
jljusten has quit [Quit: WeeChat 3.6]
alyssa has joined #dri-devel
apinheiro has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
jljusten has joined #dri-devel
ngcortes has joined #dri-devel
JohnnyonFlame has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]
danvet has quit [Ping timeout: 480 seconds]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
heat_ has quit [Remote host closed the connection]
apinheiro has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
khfeng_ has quit [Ping timeout: 480 seconds]
kkawg has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
heat has joined #dri-devel
mhenning has joined #dri-devel
<macromorgan> do you know who I can ping to look at a pending panel driver? Just want to make sure its okay and ready for mainline (it's the last bit of hardware I have for a specific device): https://lore.kernel.org/dri-devel/20220926164333.7485-3-macroalpha82@gmail.com/
mbrost has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<FLHerne> that Clover MR won't be controversial at all O.o
<karolherbst> it won't why would it be?
<FLHerne> there are at least maybe two people who actually use Clover for...something
<karolherbst> yes 1. for benchmark against rusticl and 2. for....?
warpme____ has quit []
<karolherbst> I am actually not aware of any application which seriously runs with clover. It might be fine for some data crunching stuff on r600, maybe radeonsi, but....
<FLHerne> whatever that direct LLVM IR guy was doing, I guess
<karolherbst> ahhh, that one. mhhh
<karolherbst> guess they can use rusticl once the radeonsi stuff lands?
<FLHerne> probably
<karolherbst> though they might want to try getting in some patches to ship llvm bitcodes through the il interface and I'll tell them it's a terrible again once more
mszyprow has joined #dri-devel
srslypascal is now known as Guest4394
srslypascal has joined #dri-devel
<jenatali> karolherbst: It's pretty easy to support though
<jenatali> I don't disagree that it's terrible though
<karolherbst> In rusticl it would be terribly problematic to add tho
<karolherbst> though I sometimes think if we want to compile to the hw ISA before creating cl_kernel objects, but on the other hand....
<jenatali> You can tell if the passed in binary is an LLVM blob by looking at the magic bits at the beginning
<jenatali> If so, import it to LLVM and go through the SPIR-V -> NIR path
<karolherbst> sure, but I'd convert that into spir-v and if that fails I'd return an error
<karolherbst> but
<karolherbst> the idea was to pass in hw specific LLVM bitcode
<jenatali> Oh. Oh no
<karolherbst> with amd intrinsics and stuff
<karolherbst> yes....
<jenatali> I assumed you meant the SPIR extension
<karolherbst> no
Guest4394 has quit [Ping timeout: 480 seconds]
<jenatali> 🤮
<karolherbst> yes...
zmike has quit []
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<jenatali> eric_engestrom: Third time's the charm :)
<eric_engestrom> almost
<eric_engestrom> can you cherry-pick ee9c3d2625428ac4cf4e? that should fix the docs failure
<jenatali> Yeah. Dunno what's going on with that docs job. I don't think that's my fault?
<jenatali> Ah yeah
coreforge has joined #dri-devel
<eric_engestrom> pfff
<eric_engestrom> parse error in one of the rst files
<jenatali> :(
<jenatali> Getting to close to wanting to just hit the merge button on this one so my part is done, fixing/disabling the docs job can be done afterwards
<eric_engestrom> I'd suggest diffing against main since it builds there
<eric_engestrom> you can't merge unless the ci passes though
<jenatali> Oh, you're right. That's fun
apinheiro has quit [Quit: Leaving]
<jenatali> I guess this was an upgraded sphinx on the CI runner or something that required changes to the doc files?
<eric_engestrom> this gives you the diff to fix that file: diff -up <(git show fdo/staging/21.3:docs/relnotes/21.3.0.rst) <(git show fdo:docs/relnotes/21.3.0.rst)
<bnieuwenhuizen> unlikely with containers?
<eric_engestrom> (replacing `fdo` with the name of your remote)
<jenatali> If I was using bash
<eric_engestrom> ah, I can't help in powershell xD
<eric_engestrom> (and yeah sphinx is not pinned, and a new version got stricter with syntax errors)
<jenatali> Uh... that relnotes file hasn't changed
<eric_engestrom> maybe it was fixed up between being committed to 21.3 and to main
* eric_engestrom 's memory doesn't go that far back
<jenatali> Ah, yep, your first attempt at merging !13848 failed
<eric_engestrom> indeed, good catch
djbw_ has quit [Read error: Connection reset by peer]
<eric_engestrom> I don't know why I didn't backport the fix right away
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jenatali> Ugh
<jenatali> Want to fix the docs for me? :P I don't really know what I'm doing other than playing whack-a-mole with errors as they pop up
<eric_engestrom> I'm so sorry, I did a really bad job with the docs back then D:
djbw_ has joined #dri-devel
<jenatali> I'm not in any rush to merge this MR, just wanted it so that I'm not on the hook for Windows CI in amber, but looks like docs are a bigger problem atm
<jenatali> Once they're clean the Windows change can go in
<eric_engestrom> I don't have time now, but I can have a look next week
<eric_engestrom> (ping me if I forget)
<jenatali> Sounds good
<eric_engestrom> btw you can build the docs locally to avoid the round-trip to the ci:
<eric_engestrom> docs/doxygen-wrapper.py --out-dir=docs/doxygen_xml
<eric_engestrom> sphinx-build -W -b html docs public
anholt has joined #dri-devel
<jenatali> Chances of that working on Windows... slim. I guess I could set up WSL to do it, but I suspect round-tripping to the CI would be faster overall
<eric_engestrom> haha
<eric_engestrom> fair
<eric_engestrom> anyway, I'll go now, but I'll try to fix that next week :)
<jenatali> Thanks!
<daniels> jenatali: if only Windows could run Linux containers … !
<jenatali> Heh
<eric_engestrom> perhaps using a Linux Subsystem for Windows... you could call it LSW!
<eric_engestrom> (that WSL name is so backwards)
<karolherbst> don't worry, MS will use linux in a few years anyway :P
<jenatali> Eh, it's a Windows Subsystem, it makes some sense
<bnieuwenhuizen> what gets me is the "for" as I wouldn't say it is "for Linux", while "for Windows" would fit IMO
<jenatali> I guess. It's a Windows subsystem for [running] Linux
* jenatali shrugs
<coreforge> I've got the problem that on arm64, EngineBuilder.create() in lp_build_create_jit_compiler_for_module returns a null pointer, error is something about no available targets being compatible with the triplet aarch64-unknown-linux-gnu.
<coreforge> This isn't checked for and results in a segfault
<airlied> sounds like a fatal error anywayd
<airlied> bad llvm build likely
<coreforge> it's the llvm-11 package from the debian repository, but I can try building it. clang works with the same triple on the same machine
<karolherbst> jenatali: soooooo..... somebody told me that there is this beauty of a CL ext called "cl_ext_cxx_for_opencl". You don't have any plans of supporting that one, do you?
mszyprow has quit [Ping timeout: 480 seconds]
<jenatali> Uh... where you can pass C++ to the API?
<karolherbst> yep
<jenatali> No, I had no plans of supporting that
<airlied> coreforge: seems strange then
<karolherbst> okay, good. I'd have nacked the patches anyway :)
<airlied> whats erong eith c++ for cl :-p
<jenatali> Clang doesn't support it, so we'd need an alternate way of converting it to SPIR-V
<karolherbst> clang doesn't?
<jenatali> I... don't think it does
<airlied> i thought they were.uostreaming it
<karolherbst> how do you compile OpenCL C++ code atm then?
<airlied> intel or arm had forks
<jenatali> Oh nevermind, godbot says it does
* karolherbst runs
<Sachiel> rust for opencl when
<karolherbst> jenatali: btw.. when I tried to wire up spirv I ran into funky CTS fails, wondering if you encountered the same
<karolherbst> Sachiel: through spir-v any time
<jenatali> karolherbst: Hm, I feel like I had a similar problem but it was so long ago I don't remember...
<karolherbst> honestly, people can go nuts on the frontend language as long as they give me valid spir-v
<karolherbst> jenatali: does this ring a bell? o
<karolherbst> ...
<karolherbst> I'll discuss this on tuesday on the cl working group meeting
<karolherbst> probbaly
<jenatali> No, it doesn't
<karolherbst> mhh
<jenatali> I might not have gotten around to running the CTS tests for SPIR-V
<karolherbst> ahh
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst> in case you are mildly interested, if you get something done and tested by tuesday, we could check if it's the same issue or not
<karolherbst> doesn't even need spec constants supported
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<jenatali> I have spec constants supported :P
<karolherbst> all the better
<jenatali> But yeah I'll see if I can find time to do that
<karolherbst> just run the spirv_new thing and if fmod/frem fails, it's the same issue :P
<karolherbst> but apparently they compare the spirv fmod/frem thing to OpenCL C fmod builtin, and I am sure that's not valid
<karolherbst> like the env spec doesn't define ulps on frem/fmod
<karolherbst> so the CTS can't expect them to match in precision
<karolherbst> unless I missed something
<jenatali> Then I assume I'd hit the same thing
<karolherbst> yeah.. I would be surprised if you'd hit any other bug
<jenatali> Since the SPIR-V op would get mapped to the nir op instead of libclc, which I'd just wire up natively to DIXL
<karolherbst> correct
<karolherbst> cl c doesn't have fmod anyway, so spirv fmod maps to nextafter(fmod) and frem to CL fmod, because it makes all sense
<jenatali> I was just cleaning out the issue backlog for clon12, but I hit one that's going to be hell to debug... Geekbench 5 has a failing benchmark :(
<karolherbst> heh...
<karolherbst> I tried running it and got into a runtime issue
<karolherbst> reported it to the geekbench folks, because it's impossible to debug
<karolherbst> they said "can't reproduce" and then spam bots took over the ticket ¯\_(ツ)_/¯
<jenatali> A runtime issue?
<karolherbst> yeah
<karolherbst> some exception about something
<karolherbst> dunno
<karolherbst> jenatali: "Internal error message: vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)."
<jenatali> Weird. I'm not seeing that
<karolherbst> yeah dunno.. I might not implement all APIs 100% correctly
<jenatali> Mostly works, just one of the tests is getting wrong data
<karolherbst> yeah.. a few of those did run for me as well
<karolherbst> not sure which one it crashed on
<jenatali> Also if you were curious, clang apparently does have clc++ support, but it doesn't fully work when going to SPIR-V: https://godbolt.org/z/W34v13ne1
<karolherbst> *sigh*
<jenatali> The LLVM IR looks good but the SPIR-V makes the global constructor the only kernel in the output
<karolherbst> heh...
<karolherbst> huh.. not seeing that though?
<jenatali> OpEntryPoint Kernel %56 "_GLOBAL__sub_I_example.cl" %_str
<karolherbst> ohhh
<jenatali> %56 is a function that calls the constructor and returns
<karolherbst> duh
<karolherbst> yeah..
<jenatali> No other entrypoints in that file
<karolherbst> seeing that now
<karolherbst> though there is _Z10do_add_subPU3AS1Dv4_sS1_S1_S1_ ...
<karolherbst> but no entrypoint decl for that one
<jenatali> Yeah it's there, it's linkage-exported, but not a kernel in this SPIR-V
<karolherbst> though you should be able to do that with a normal clang
<jenatali> karolherbst: Anybody in particular that you think should review/ack that interop MR? Otherwise I'll probably merge it on Monday with your ack
<jenatali> Eh should probably wait longer than that I guess
ahajda_ has quit []
coarforge has joined #dri-devel
coreforge is now known as Guest4401
coarforge is now known as coreforge
Guest4401 has quit [Ping timeout: 480 seconds]