00:14marex: hey, if I have two identical cards (imx-lcdif) in a system , can I somehow discern them with 'modetest' ?
00:14marex: it seems no matter what I pass to modetest -D , it always picks the second card
00:14marex: i.e. /dev/dri/card1
00:15marex: it never picks /dev/dri/card2 even if I use modetest -D /dev/dri/card2
06:56dj-death: looks like CI is having some kind of issue : https://gitlab.freedesktop.org/mesa/mesa/-/jobs/42182123
06:57dj-death: some kind of network timeout maybe?
07:19pq: mairacanal, no, my comment was completely based on reading the patch. Thank you for running benchmarks. I am extremely surprised the performance did not worsen significantly, but if that's a true result, I'll leave it at that.
07:25pq: marex, you
07:25pq: marex, you're not the first one to complain recently that one cannot pick the right card with modetest.
07:26pq: marex, maybe modetest needs fixing, or if you only want to inspect instead of test, then drm_info is nice.
10:26melissawen: daniels, greetings to mairacanal, it's mainly her effort on keeping VKMS stable \o/
10:28emersion: :)
10:38marex: pq: I already sent a patch yesterday
10:39marex: pq: https://patchwork.freedesktop.org/patch/538340/
10:39marex: pq: that -D device parameter doesn't do what I expected it to do took me by surprise all right
10:43pq: makes me wonder how anyone was able to introduce -D without that
11:06karolherbst: what's the general rule about trivial compile time fixes (like function prototype stuff) and what branch they go to? Is it fine to send them for fixes or should that just go to next?
11:07karolherbst: mhh.. trivial isn't the best phrase here, maybe "Werror Wall" stuff? dunno
11:34ManDay: Hi, just a quick dependency question: Why does Mesa with vulkan support depend on libclc (as by the Gentoo ebuild 23.1)?
11:34karolherbst: Intel uses it for raytracing
11:34ManDay: Ah okay, thanks!
11:35karolherbst: yeah.. apparently it was simpler to write the code in OpenCL C and use that
11:35ManDay: :D
11:37karolherbst: not sure if Intels raytracing code actually requires libclc, but it's a dependency of our OpenCL C compiler infra
11:40ManDay: Right.
11:40dj-death: it's a build time dependency
11:40ManDay: You don't happen to know the relation between that and LLVM SPIRV support?
11:40ManDay: I'm just wondering, because I just spotted LLVM having a SPIRV flag
11:40ManDay: (and it's coincidentally LLVM which is being pulled in by libclc)
11:41ManDay: (just curious)
11:41dj-death: we compile OpenCL code to SPIRV and have the mesa SPIRV parser/compiler turn it into Intel GPU assembly
11:42ManDay: ah ok, i take it llvm's support is to compile TO spirv
11:42ManDay: But not from OpenCL
11:42kisak: last I heard, llvm's newer spirv backend was incomplete and not battle tested in the wild.
11:44dj-death: opencl -> llvm-ir with libclc
11:45dj-death: then llvm-ir -> spirv with llvm-spirv
11:47ManDay: i see. the USE flags in Gentoo are still a bit mysterious to me, but from the mesa perspective it all makes perfect sense :)
11:48ManDay: (like we have libclc +spirv, and llvm -spirv, but then comes spirv-llvm-translator ...?!)
12:11cwabbott: gfxstrand: can you take a look at the common parts of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22301?
12:16jenatali: ManDay: Clang is the bit that translates to LLVM IR, then llvm-spirv translates to SPIR-V. libclc is the C standard library which provides implementations of math/memory routines that we link in. They're precompiled to SPIR-V
12:20ManDay: jenatali: Ah thank you for the excellent explanation!
12:22ManDay: however it is weird that with that, SPIRV support on LLVM/Clang is disabled in that setup...
12:23ManDay: (again: according to the Gentoo ebuild)
12:32tomeu: ManDay: I guess Mesa is still using the out-of-tree llvm->spirv translator: https://github.com/KhronosGroup/SPIRV-LLVM-Translator
12:32tomeu: so the backend in LLVM is not used yet
12:33ManDay: tomeu: ah, it's been incorporated into llvm? yes, it's a separate package
12:33ManDay: I see, that explains why USE=-LLVM_TARGET_SPIRV
12:33tomeu: it was intended to a few yeards ago, but I haven't been following it since
15:08alyssa: zmike: re https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23142#note_1917774
15:08alyssa: the reason I said you'd hate it was because, I'm assuming either
15:08alyssa: 1. this will cause pain for vulkan (since zink doesn't currently have this flag), or
15:08alyssa: 2. there is some way to recover this information in gallium (if vulkan needs it, since zink doesn't have the flag)
15:09alyssa: (unless maybe vulkan needs it and it's worked on existing vk drivers by chance and this lets zink fix that. but that seems less likely.)
15:09alyssa: dEQP-GLES31.functional.image_load_store*load_store*single_layer
15:10zmike: usually I just infer single layer and it's correct
15:11zmike: having the flag would disambiguate for single slice 3d
15:12zmike: but I've never seen that fail
15:23alyssa: right. Maybe we should add CTS tests for that.
15:23alyssa: otoh I don't care :p
15:25zmike: piglit probably covers it
15:29alyssa: shrug
15:30alyssa: I guess I'll merge with the r-b+a-b, and if someone wants to change Zink to use it they can
15:38zmike: yeah it's a one liner I'll get around to at some point
15:41alyssa: :+1:
18:04zf: I think piglit's 8b5ada9ffa94fe40a170619c4b94a2db35de8efb broke the build
18:05zf: since PIGLIT_BUILD_GLX_TESTS isn't actually set by default?
18:06zf: the commit also doesn't seem to make sense to me. why would disabling GLX tests imply that the system doesn't actually support GLX?
20:07DavidHeidelberg[m]: Anyone with CPU detection rutines in their head? Need review of adding one small check to make compiler happy: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23164
20:29HdkR: DavidHeidelberg[m]: Can't it just get moved up to the previous `if (regs[0] >= 0x00000001) {` check?
20:32HdkR: Actually, this seems like it was abusive prior anyway. Was using CPUID leaf `0x00000007` without checking for `regs[0] >= 0x00000007`
20:33HdkR: Also could have been a subset of the `if (util_cpu_caps.has_avx && regs[0] >= 0x00000007) {` check instead.
20:34HdkR: Since there isn't going to be an AVX512 check if it doesn't already support AVX and RAX >= 7 anyway
20:39DavidHeidelberg[m]: HdkR: I think the logic of the if is right, but compiler doesn't know
20:39DavidHeidelberg[m]: but maybe in future there will be CPU without AVX and with AVX512 :D
20:41HdkR: Logic is currently broken on a CPU that doesn't expose CPUID functions beyond 1. Which TBF is going to be no one
20:45HdkR: DavidHeidelberg[m]: https://gist.github.com/Sonicadvance1/d5cd96a1151f154bda2992b5972a08c9 Should be something like this. OSXSAVE already checked by the has_avx check.
20:45HdkR: Actually, that can be cleaner..
20:46HdkR: There we go, reuse the regs7 variable instead of querying again the data that was already checked.
20:54DavidHeidelberg[m]: HdkR: look good! Thanks
20:57jenatali: Woo managed to get all of the custom *_dxil nir intrinsics deleted locally. Should be a fun MR to review lol
21:03DavidHeidelberg[m]: HdkR: thx, I just replaced patch with yours (and changed authorship) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23164/diffs
21:07HdkR: +1
21:08alyssa: jenatali: noice
21:08alyssa: I used to try to do Totally Pure Common NIR
21:22DavidHeidelberg[m]: last kind request for review. Great opportunity for someone who loves type conversion between float, int. Someone who loves rounding and getting the right number in the end: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22813
21:22alyssa: DavidHeidelberg[m]: I see your nerdsnipe and it is owrking
21:24DavidHeidelberg[m]: :D
21:26DavidHeidelberg[m]: This is one of latest blocker (except the previously one solved by HdkR ). After this I can uprev CI to Debian 12, so we can switch more tests from Xorg to Wayland, use new libs & better gcc and clang.
22:54jenatali: alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23173 :)
22:54jenatali: Probably still needs some CI iteration before I remove draft
22:56alyssa: jenatali: nice
22:56alyssa: meanwhile I'm in over my head with the nir_reg deletionism
22:56alyssa: Using my magic powers to summon a wild gfxstrand to help
22:56jenatali: Is it working?
22:57alyssa: IDK yet
22:57alyssa: "try adding a pipe cap"
22:57alyssa: NOooooooOooOooooO
22:57alyssa: zmike: get the water spritzer
22:58jenatali: Yeah adding a pipe cap is on my list for a followup to this series too
23:00zmike:resets the Days Since New Pipe Cap counter