09:47 Jules: I've got an MR with an NVK implementation of a new extension, the anv and radv implementations have already been reviewed, I'd really appreciate a review from nouveau if anyone has time: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31411
09:50 Jules: The extension is fairly trivial so it only requires reviewing 13 lines in 2 files
15:22 gfxstrand[d]: I'll look at it later today. I was fighting COVID the last two weeks which is why I've not been very responsive. I should be back now, though.
15:22 tiredchiku[d]: glad you're feeling better now :saigeheart:
16:11 Jules: Oh damn, good to hear you're feeling better though. The MR is only 3 days old, so no worries I just wanted to reach out.
16:11 Jules: I'm still trying to get the pipeline to pass
16:45 valentineburley[d]: Jules: You don't need to, none of the fails there are your fault
16:46 valentineburley[d]: all the failures are pre-existing stuff unfortunately
16:47 valentineburley[d]: and CI doesn't even have an up-to-date CTS with your tests
17:21 Jules: valentineburley[d]: That's good to know thanks, I just wanted to ensure I wasn't breaking anything new
18:53 demonkingofsalvation[d]: might be addressed somewhere else, but is it possible to use cuda with nouveau or is there some fundamental flaw in cuda that doesn't allow an open source implementation?
19:21 gfxstrand[d]: Jules: Left you a few comments
19:21 gfxstrand[d]: demonkingofsalvation[d]: NVIDIA has said they'll sue anyone who re-implements CUDA
19:21 demonkingofsalvation[d]: damn, that's kinda messed up
19:22 demonkingofsalvation[d]: so either use their drivers or piss off?
19:22 gfxstrand[d]: It's specifically targeted at AMD and Intel who have both toyed with providing CUDA on their hardware to try and take some of NVIDIA's pie. I don't know how they would feel about an open-source implementation on top of NVIDIA hardware.
19:23 gfxstrand[d]: But also, pissing of NVIDIA isn't on my 2025 ToDo list.
19:24 demonkingofsalvation[d]: ah I see, so even if someone did implement it, we wouldn't know if it would be taken down, RIP
19:24 gfxstrand[d]: And I think the better thing long-term is to make some of the alternatives to CUDA actually usable.
19:25 demonkingofsalvation[d]: I'm just a beginner, so like ZLUDA or something else?
19:25 gfxstrand[d]: Like better OpenCL and Vulkan compute. Or maybe some secret 3rd thing that's still based on SPIR-V.
19:26 demonkingofsalvation[d]: rip, guess my noob skills aren't going to help with that XD
19:35 airlied[d]: I don't think NVIDIA have said that
19:35 airlied[d]: They also haven't threatened AMD or Intel
19:35 airlied[d]: The EULA change was AFAICS targeted at hw cloners who were running SASS binaries on non-NVIDIA hw
19:36 airlied[d]: AMD disengaged ZLUDA for their own internal legal reasons, might be a risk increase from the EULA changes, but it wasn't directly related
19:37 karolherbst[d]: AMD can also just make HIP be better
19:39 airlied[d]: I think if you write a SASS transpiler or design hw to run it, then you should probably lawyer up, but doing a open source CUDA runtime like librecuda on NVIDIA hw is fine
19:40 karolherbst[d]: yeah... probably, I mean they even document PTX, so....
19:40 karolherbst[d]: and the driver API
19:42 airlied[d]: I failed to learn enough about parsers to write a PTX parser in rust yet
19:42 karolherbst[d]: we need that to implement this vulkan extension anyway 😄
19:42 airlied[d]: ZLUDA has one, but the ZLUDA dev said they wanted to rewrite it
19:43 karolherbst[d]: I wonder if it makes sense to write a standalone PTX to LLVM/SPIR-V thing
19:43 marysaka[d]: isn't there already a PTX parser in LLVM? :aki_thonk:
19:43 karolherbst[d]: a PTX backend, yes, not sure there is a parser
19:43 mohamexiety[d]: airlied[d]: iirc it was Moore Threads who promised CUDA compatibility (with no modifications) with their GPUs
19:44 mohamexiety[d]: the change appeared shortly after
19:51 Jules: gfxstrand[d]: Thanks for the review, I've addressed the comments
20:06 airlied[d]: mohamexiety[d]: that would be more along the lines of what I heard
20:18 gfxstrand[d]: airlied[d]: Yeah, that makes sense.
20:18 gfxstrand[d]: But also, if AMD and Intel are scared off, IDK that I want to stick my neck out there.
20:19 gfxstrand[d]: I'm also of the opinion that an open-source CUDA implementation would only serve to further cement CUDA in as the API du jour in the compute ecosystem.
20:23 airlied[d]: yup the latter is my main reason against doing it, having a non-standards driven defacto that is tied to one hw manufacturer isn't really living the dream
20:24 gfxstrand[d]: And the real problem isn't that there aren't other options. It's that the implementations suck.
20:24 gfxstrand[d]: Which, on the part of AMD and NVIDIA, is semi-intentional.
20:25 karolherbst[d]: AMD's CL stack isn't even conformant
20:26 mohamexiety[d]: the kinda meh thing is that this does block off some of the fancy stuff for gaming like DLSS since from what I understood it's CUDA underneath
20:26 karolherbst[d]: there is a Vulkan extension to run CUDA kernels, which _might_ be useful for that
20:27 karolherbst[d]: but yeah... PhysX was also CUDA under the hood for a long time
20:27 airlied[d]: I think some of that stuff doesn't even have PTX kernels
20:27 karolherbst[d]: would kinda suck for games
20:28 tiredchiku[d]: karolherbst[d]: hub
20:28 karolherbst[d]: how would you make sure the stuff works on future GPUs given that games might be terrible with updating their shipped stuff
20:29 mohamexiety[d]: oh games basically dont update DLSS at all
20:29 karolherbst[d]: yeah, I know
20:29 karolherbst[d]: hence shipping GPU binaries sounds like a terrible idea
20:29 mohamexiety[d]: people just swap dlls or use programs that swap them :KEKW:
20:29 karolherbst[d]: tiredchiku[d]: `VK_NV_cuda_kernel_launch`
20:30 karolherbst[d]: I think there was another newer one
20:31 tiredchiku[d]: fascinating
20:32 airlied[d]: I think a rust nom based parser for PTX would be interesting, but I've no idea if nom is sufficent for the task
20:45 gfxstrand[d]: Unfortunately, PTX doesn't really have a spec, which makes things harder. It has decent docs but that's not the same as a language spec.
20:45 gfxstrand[d]: And then there's the question of what to parse it into. It's pretty NVIDIA-specific. I think with enough NIR intrinsics, it could be done, but it's unclear what the right flow would be.
20:47 airlied[d]: yeah if it needed to be treatedlike GLSL or SPIR-V inside mesa was kinda an open question, like does it need full compiler frontend treatment etc
20:48 airlied[d]: I should troll someone into porting GLSL parser to rust nom first 😛
21:05 gfxstrand[d]: Oof....
21:06 gfxstrand[d]: IDK if that's a great idea or a terrible one
21:06 magic_rb[d]: under different circumstances, that sounds like something i could get nerd sniped for
21:16 Jules: gfxstrand[d]: Unfortunately the `SET_DYN_VALUE` macro does not support structs, so I went back to the earlier vulkan runtime commit with the indenting changes applied to it
21:16 gfxstrand[d]: Okay, that's fine.
21:16 gfxstrand[d]: I thought it did
21:17 Jules: It doesn't, it uses != and = instead of memcmp and memcpy
21:18 Jules: I guess assignment would work, but the comparison would not
21:20 gfxstrand[d]: Yeah
21:21 gfxstrand[d]: I think I had some reason for not using `memcmp()` but I don't remember what it was.
21:21 notthatclippy[d]: Padding.
21:25 gfxstrand[d]: Yeah, that'll do t
21:27 Jules: btw, is there a discord server for nouveau? I get a strong feeling a discord bridge is being used on this IRC channel ^^
21:30 gfxstrand[d]: https://discord.gg/W3WS8BxU
21:38 karolherbst[d]: the good part is that not even nvidia gpus support everything which is in ptx
21:39 karolherbst[d]: does ptx have quad ops I wonder? those would be painful to lower
21:43 notthatclippy[d]: karolherbst[d]: "This could feasibly be a specialized instruction in $nextchip, but for now we emulate the intrinsic."
21:43 notthatclippy[d]: ~~$nextchip was probably 10 years ago~~
21:43 karolherbst[d]: I'm sure nvidia never planned to add 3d texgrad 😄
21:45 notthatclippy[d]: That could have been a thing in Tesla era. Before my time.
21:45 karolherbst[d]: I mean.. GL requires it anyway, so might as well add it to ptx, but yeah....
21:49 blockofalumite[d]: Just wondering, do I remember it right that the Gallium GL driver was deprecated and instead NVK + Zink is to be used for newer NVIDIA cards? I remember reading it in a Phoronix article but rather making sure I don't spread misinfo
21:49 karolherbst[d]: that's certainly the long-term plan
21:50 blockofalumite[d]: And the current state? Aka, how much work is being put into the Gallium GL driver vs NVK ?
21:51 karolherbst[d]: almost none vs a lot, but the problem is testing and people reporting issues to actually drive the entire desktop
21:51 airlied[d]: 0 vs not-0 🙂
21:53 blockofalumite[d]: Drive the desktop?
21:55 karolherbst[d]: like to run your compositor and any other app
22:00 blockofalumite[d]: I am unsure I follow, so the current main issue is a lack of testing and bug reports ? Or
22:02 gfxstrand[d]: airlied[d]: anything in particular I should talk about RE kernel in my nouveau/NVK update?
22:05 airlied[d]: nothing really affecting much, shout-out to nova happening, but in terms of userspace impacts not much
23:12 redsheep[d]: Has anyone else tested chromium corruption with nvk+zink on Ada recently?
23:13 redsheep[d]: Cuz that is easy to test with discord in particular, and if it still corrupts I'd say defaulting is still a bad idea
23:13 redsheep[d]: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11160
23:13 redsheep[d]: Much less difficult to test than sessions
23:19 redsheep[d]: My theory was there's something wrong with DMA bufs since chromium would be one of the only users of those that isn't a compositor. I can't test myself at the moment as my computer is occupied running windows stuff for the next while.
23:22 redsheep[d]: tiredchiku[d]: maybe you want to have a go on ampere, or gfxstrand[d] this should be easy to test on your ada laptop to know whether zink is stable for your talk