00:53 karolherbst: miserable revelation of the day: the poison guarantee in SPIR-V glsl fclamp is actually useful for us...
09:11 kode54: wait, the cross posted viln was
09:11 kode54: *vuln was amdgpu?
09:12 kode54: trend micro cross posted something this morning
09:12 kode54: or it was undated and my client dated it when it received it
09:14 pitust: hi, i'm (trying to) write a userspace driver for amdgpu gfx11 (for fun), but i'm struggling to get a triangle to draw reliably (it seems to work, about ~75% of the time). does anyone know what could cause this? (code: https://git.sr.ht/~pitust/vgi/tree/trunk/item/src/main.cc#L249, the mess of register writes is copied from a recording of what mesa does except mesa works every time)
09:14 pitust: sorry if this is not the right place for this kind of question btw
09:17 pitust: compute works reliably every time though
11:20 fufexan: melissawen: I've opened an issue about the HDR -> WCG problem here https://gitlab.freedesktop.org/drm/amd/-/work_items/6027
12:08 DragoonAethis: pitust: you should try #radeon too
12:08 DragoonAethis: more AMD userspace folks sit over there
13:36 karolherbst: Soo.. looking into VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD and external memory. Seeing that not all content is properly synchronized over the API boundaries. Is there anything special about VK_MEMORY_PROPERTY_DEVICE_COHERENT_BIT_AMD in that regards?
13:37 rodrigovivi: airlied: it looks the freeze is working and the unified drm-for-linux-next is avoiding all -next branches and only getting the drm-next and all -fixes... Monday we can confirm that after -rc1 we are back to pull everything but the topic branches, then we would be ready to sync with all the maintainers and make the switch
13:45 alyssa: pendingchaos: this code is human slop but https://gitlab.freedesktop.org/alyssa/mesa/-/commit/116a3c3c4f4839ef8b39a9f40e647dbcf8124abe as a rough idea might be worth it
13:52 WeaselSoup: Hi, I have an OrangePi6Plus (Cix CD8180 with I think a "Arm Immortals G720 MC10"). I'm looking at Mesa / virglrenderer and I'm curious is there is anything to do/compile to take advantage of the integrated GPU.
13:52 WeaselSoup: https://fedoraproject.org/wiki/Architectures/ARM/CD8180
13:56 alyssa: panfrost/panthor/panvk
14:01 WeaselSoup: ty
14:03 WeaselSoup: The vendor distribution offers a "mali_kbase" module with no DRM node (linux 6.1.44)
15:38 robclark: Hmm deqp surfaceless platform doesn't implement getEGLPlatform(), so `No EGL configs enumerated: EGL is not supported at tcuPlatform.cpp:49`.. how actually is this even supposed to work? (Basically this bug: https://github.com/KhronosGroup/VK-GL-CTS/issues/462)
15:51 HdkR: It was supposed to work?
15:54 zmike: configure with DEQP_TARGET=surfaceless
15:54 robclark: running (for ex) glcts directly with a caselist seems to avoid this.. somehow.. but cts-runner hits this. I guess I could just build with something other than surfaceless platform. But I'm confused about why surfaceless platform doesn't support EGL.. since, like, how else is surfaceless supposed to work
15:54 robclark: yeah, I am using DEQP_TARGET=surfaceless
15:54 zmike: 🤔
15:54 swick[m]: So I just noticed that calling drmHandleEvent on a fd for a device that was removed hangs forever
15:56 swick[m]: I'm like 90% sure that this is a kernel issue and that read() should return as soon as a device goes away. I'm just really confused why I seem to be the first one hitting this
15:58 swick[m]: /cc MrCooper
15:59 karolherbst: I don't think we ever got a plan working for devices suddenly disappearing and.. I think that's where everything is at
16:01 swick[m]: I mean, you dont need an great plan for this, but there is literally no way out of a blocking read if the device disappears
16:01 swick[m]: that by itself already sounds very much not useful
16:28 HdkR: SIGPIPE and explode
16:32 MrCooper: swick[m]: I don't disagree, what do you expect me to do about it though? :)
16:34 swick[m]: not sure, maybe know who would be willing to fix this? :p
16:39 MrCooper: not sure who might be offhand
16:40 MrCooper: what's the use case out of curiosity, eGPU hot-unplug?
16:40 swick[m]: tests via vkms configfs
16:41 MrCooper: ah
16:41 swick[m]: but turns out that nicely tests all your egpu hotplug paths as well
16:43 swick[m]: I'm working around it now via poll with an evenfd that fires based on udev events
16:43 MrCooper: sounds racy
16:43 MrCooper: I wonder if opening the fd with O_NONBLOCK might help
16:44 HdkR: Ripping your GPU out of the PCIe slot is also a race so there isn't going to be a lesser evil :D
16:44 swick[m]: that's what I'm doing with the poll. throw in the device fd and the eventfd.
16:44 swick[m]: but yeah, doesnt really matter when the udev event arrives, we just need to eventually get rid of the device it in mutter.
16:45 MrCooper: the fd might be considered readable if there were events queued when the device was removed
16:46 swick[m]: yes, but then read with noblock will work just fine
16:47 MrCooper: now I'm confused how you ended up with a blocking read
16:48 swick[m]: with a blocking read :P
16:48 MrCooper: the fact that you tried reading means the fd was considered readable, right?
16:49 swick[m]: no, the code currently does a blocking read on the fd, but if the device goes down during it or before it, it never unblocks
16:50 swick[m]: and I changed it to a poll with the device fd being O_NOBLOCK and an eventfd which fires on udev device-removed
16:51 MrCooper: offhand that sounds saner than a blocking read, what was the reason for the latter?
16:53 MrCooper: there's still a potential race where an event is queued on the device, the device is removed, user space tries to read from the fd; I wonder if that might still hang even with O_NONBLOCK
16:55 swick[m]: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-kms-impl-device.c?ref_type=heads&blame=1#L504
16:58 MrCooper: yeah that looks a bit backwards :)
16:59 MrCooper: poll then drmHandleEvent seems better
16:59 swick[m]: i dont think the poll does anything there anyway
17:00 swick[m]: drmHandleEvent is just a block read
17:02 MrCooper: actually AFAICT that poll call blocks until the fd is readable or has an error condition
17:02 MrCooper: maybe just need to break out of the loop on the latter?
17:05 MrCooper: anyway, the church bells are announcing beer o'clock, bbl
17:07 swick[m]: o/
17:14 zamundaaa[m]: <swick[m]> "I'm like 90% sure that this is a..." <- You're likely the first hitting it because everyone else only calls drmHandleEvent when the fd is readable
17:21 swick[m]: must be it, but that is a bit surprising to me
17:26 zamundaaa[m]: It's a completely natural thing to do when you have event loops
18:45 medichon: sudo apt update
18:45 medichon: wc
19:54 karolherbst: do we have a nir opt that merges nested ifs? like "if (a) { if (b) { ... } }" -> "c = a && b; if (c) { ... }"?
20:04 glehmann: nir_opt_collapse_if in peephole_select?
20:07 karolherbst: mhhhh yeah.. maybe
20:08 karolherbst: I have a shader where it's not triggering, haven't tried to look why not tho
20:31 mhenning: oh, that might just be that we have limit = 0 then
20:36 karolherbst: yeah..
21:24 glehmann: limit = 0 is probably not a good idea even if your branches were free
21:29 karolherbst: yeah.. they are very much not free.. the contrary 🙃