00:07 karolherbst: alyssa: okay, I'll try to come up with a proper patch tomorrow then or something
00:07 alyssa: (well first https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41671 needs to fail ci because of this)
01:08 karolherbst: alyssa: I guess it's just flaky? Because otherwise the MR landing that patch should have failed
01:15 karolherbst: alyssa: ... it's more evil than that. Sooo.. so the drop handler calls into util_queue_finish :)
01:18 karolherbst: uhhh.. _pain_...
01:18 karolherbst: at least I understand what's going on
01:20 karolherbst: So the closure passed in has a reference to a cl_program object, which has a reference to a cl_context object. Which owns the queue, so tidying up those references leads to a dead lock. I guess I have an alternative solution: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40663/diffs?commit_id=ea855bea54c8f86680b49419cbb7064b86f2d160
01:20 karolherbst: I can move this out of the MR and submit it on its own 🙃
02:18 alyssa: karolherbst: will check tomorrow, landing the revert as a hotfix so merges aren't blocked though
02:30 karolherbst: alyssa: idea would have been to land my MR instead, but we can also revert first :D
02:34 alyssa: karolherbst: it's 10pm here :p
08:44 tzimmermann: pcercuei, hi. i have a patch series that modifies damage handling. this also affects the ingenic driver. it's patch 9 of https://lore.kernel.org/dri-devel/20260610152505.260172-1-tzimmermann@suse.de/ could you please take a look?
15:22 alyssa: karolherbst: now i'm wondering why basic vload_private has started failing in cts runner but passing in isolation o.o
15:23 karolherbst: mhhhh... maybe some odd race? dunno...
15:23 karolherbst: there are a couple of tests that fail due to memory usage
15:23 karolherbst: alyssa: you can get the sub-tests log in the runner
15:23 karolherbst: just uhm.. remove the comment thing
15:24 karolherbst: "#print(result)" -> "print(result)" will print the entire thing with stdout and stderr
15:30 alyssa: thx
15:32 karolherbst: kinda wished deqp-runner would be up to the task, but the "we are only splitting the log" isn't really working too well with the CL CTS given the massive size of some of those tests
15:37 alyssa: karolherbst: Testing long2...\nERROR: Data sample 0 for vload of long2 did not validate (expected {f6b29a580e84bdd8 6229393a45cccd8c}, got {0e84bdd80e84bdd8 45cccd8c45cccd8c}, loaded from offset 3)\nFailure; skipping further sizes for this type.Testing ulong2...\nERROR: Data sample 0 for vload of ulong2 did not validate (expected {f6b29a580e84bdd8 6229393a45cccd8c}, got
15:37 alyssa: {0e84bdd80e84bdd8 45cccd8c45cccd8c}, loaded from offset 3)
15:37 alyssa: uhhh.... lovely.
15:37 alyssa: how would that not happen in isolation? o-o
15:37 karolherbst: uhhh.. pain
15:37 karolherbst: synchronization?
15:37 alyssa: oh wait now it's repro'ing isolation
15:37 alyssa: hahah what
15:38 karolherbst: :')
15:38 karolherbst: maybe some funky alignment fuck up?
15:38 alyssa: what is the difference between these two identical windows
15:39 karolherbst: seems like I do have "basic vload_private" failing here as well on my laptop mhh...
15:40 karolherbst: but mhh passes in isolation.. annoying
15:40 karolherbst: not sure I ever debugged this, but might be something silly..
15:40 alyssa: seemingly one of these is my meson devenv and the other isn't
15:40 alyssa:rages
15:41 karolherbst: :')
15:41 karolherbst: ohhh so it got fixed in the meantime
15:41 karolherbst: I wonder...
15:41 alyssa: I think this is a "pass with jay, fail with brw" one
15:42 alyssa: and I somehow have been testing the wrong compiler. lovely
15:42 alyssa: oh good grief
15:43 alyssa: the "use jay" env var changed. i think i've been doing brw runs for ages then. oof.
15:43 alyssa: embarasing
15:44 karolherbst: it passes here without jay
15:44 glehmann: best way to avoid regressions
15:46 alyssa: glehmann: legit
15:50 alyssa: well kicked off a new CTS run to find out what I've broken then (:
15:51 karolherbst: mhh maybe I should reverse bisect this to figure out if there is a legit fix and what it was
15:55 alyssa: karolherbst: or just switch to jay
15:55 karolherbst: alyssa: does it support MTL already?
15:55 alyssa: oh, no, not yet
15:55 karolherbst: my other system is ADL :)
15:56 alyssa: (for Xe2+ at least rusticl should be strictly happier with jay but there's a bunch more way for gl/vk and switching just CL doesn't make sense)
15:56 alyssa: s/way/work
15:59 karolherbst: mhh right
15:59 karolherbst: could use jay for compute shaders only 🙃
18:38 glehmann: is vulkan_resource_reindex valid for acceleration structure?
18:38 glehmann: I can pass CTS while not implementing it, but not sure that means anything
19:35 FireBurn: airlied: Hey, do you still have access to a DisplayLink device?
19:57 FireBurn: And does anyone have any ideas (sort of buying a USB traffic analyser) that might help pinpoint my DiplayLink Vino issue?
20:00 airlied: FireBurn: I'm sure I've got some in some box somewhere
20:03 FireBurn: I've gone onto the codec in the meantime
20:04 FireBurn: I've been doing everything I can think of to try and capture what DLM is doing to see what's missing from Vino, but I think the timings and orderings and encryption are all correct
23:06 karolherbst: alyssa: okay.. "brw: scalarize even 64-bit scratch access" fixed it 🙃