00:00 ngcortes: i'll post a pathological example here in a moment
00:18 anholt: ngcortes: sounds like your kernel recovery might be busted?
00:39 ngcortes: anholt, thing is we're running a production kernel :/
00:39 ngcortes: maybe we have some weird kernel params set?
00:40 ngcortes: we're running 6.17.0 in CI
00:50 airlied: setting the iommu to on will either slow things down or stop some fault, but it's more likely a kernel driver bug than anything
01:07 ngcortes: airlied, guess i could file a bug on jira
02:10 ngcortes: anholt, is there are recommended way to set the "tests_per_group" param in deqp-runner? I'm dividing the total caselist count by the number of threads run. maybe that's not right? seems like my test runs slowed down a lot
02:11 ngcortes: compared to directly calling the binary on multiple child processes
02:12 ngcortes: i could also be running on slow hardware but i'll need to confirm that
02:13 anholt: definitely not right. Take a look through mesa ci -- we generally use 5000 for VK (amortizing its worse startup time), default (500) for GL. In deqp-runner git, we default to 5000 for VK.
13:03 jani: airlied: sima: drm-tip build broken again https://lore.kernel.org/r/3a184e3f3c0623107caf400511905ba9d0851424@intel.com
13:50 MrCooper: jani: it's the silent merge conflict airlied called out in the drm-next PR for 6.19, the are_sinks_equal & hdmi_hpd_debounce_work functions are duplicated
14:03 jani: MrCooper: maybe, but needs to be fixed in drm-tip no matter what
16:55 rcv11x: hi
16:56 rcv11x: mesa 25.3.1 hype hype, it's supposed to be released today after last week's delay, right?
16:56 rcv11x: I'm so excited
17:03 cwabbott: gfxstrand: turns out fixing what you broke is going to be non-trivial
17:04 cwabbott: vulkan says that a lot of builtins like Layer and ViewIndex have to have a "scalar integer value" but don't specify the signedness
17:04 cwabbott: glslang happens to emit signed integer types for them
17:06 cwabbott: that type gets carried through by lower_sysvals_to_varyings when everything is still variables
17:07 pac85: somehow everything improved except the thing I wanted to improve (min fps) https://www.irccloud.com/pastebin/UWkf7U6Q/
17:10 cwabbott: so we wind up with a signed ViewIndex/Layer varying before lower_input_attachments, and then when lower_input_attachments inserts a sysval intrinsic it hits the intrinsic lowering which expects the type of the existing variable to be unsigned and it asserts in nir_get_variable_with_location()
17:13 cwabbott: there are a few different ways to deal with this and they are all ugly
17:14 cwabbott: rewriting the variable type when lowering to varyings is possible but not straightforward
17:16 cwabbott: vtn isn't really setup to be able to change the variable type
17:16 cwabbott: I'm not sure if we want to weaken the assertion in nir_get_variable_with_location()
17:18 cwabbott: if we can't come up with a solution in the next few days I'll have to revert some of !38562
17:32 cwabbott: oh right, normally we call nir_lower_system_values but that happens after nir_lower_sysvals_to_varyings which keeps the integer type preserved
17:32 cwabbott: but only for layer...
17:40 cwabbott: I think I can probably fix turnip by always calling lower_sysvals_to_varyings after lower_system_values so that we always hit the intrinsics path, but this is still a huge footgun
18:45 anholt: cwabbott: couldn't we just have the pass move off of nir_find_variable_with_location() to nir_find_variable_with_location() and a manual nir_create_variable_with_location() fallback?
18:56 karolherbst: pac85: probably higher compile times?
18:59 pac85: karolherbst: I mean the low FPS number is within error of measurement it's just funny that it's all backwards. Anyway benchmarks are bad for testing this because they compiler every shader beforehands and don't really tend to hit too many emulation paths in zink
18:59 karolherbst: ahh...
19:00 pac85: I found a particular place in a game that benefits though
19:01 pac85: Anyway the point was to also see if I'm regressing general performance and it seems I'm not
19:04 cwabbott: anholt: yeah, although at that point I'd wonder if we should just change the assert
19:05 cwabbott: my fix winds up deleting code so we should probably still land it
19:05 cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38793
19:06 anholt: cwabbott: assertion is my fault, works for me, tbh.
19:31 dcbaker: zzyiwei: I have "venus: fix racy semaphore feedback counter update" queued for 25.3, but it's conflicting in a way that is more complicated than I feel confident resolving. If you'd like that to get merged for 25.3, can you backport and open a PR against the staging/25.3 branch?
19:36 dcbaker: hakzsam: I've got "radv: add workaround for bad memory management with Red Dead Redemption 2" and "radv: reduce maxTexelBufferElements to 1<<29", neither of which apply cleanly and neither of which I feel confident backporting. Could you create a PR for me?
20:04 hakzsam: dcbaker: sure, I will create it tomorrow
20:09 zzyiwei: dcbaker: thanks for letting me know. Np, I'll handle that
20:30 dcbaker: hakzsam, zzyiwei thanks!
21:05 ngcortes: anholt roger thanks!
23:19 zzyiwei: dcbaker: here we go: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38799
23:31 airlied: jani: should be fixed now I think