Thermi has quit [Read error: Connection reset by peer]
Dark-Show has quit [Remote host closed the connection]
_xav_ has quit [Ping timeout: 480 seconds]
_xav_ has joined #zink
i509vcb has quit [Quit: Connection closed for inactivity]
pac85 has joined #zink
<pac85>
zmike: One think I notediced while debugging that issue with the selaco trace is that it runs really slow on zink, independently on whether pv emulation is taking place. However it runs fine on an older version of zink shipped by the distro I use. Is there a known performance regression or should we take not of this somewhere?
<zmike>
I haven't seen it running slowly here?
<zmike>
what driver are you on
<pac85>
radv
<zmike>
I get a lot of fps on radv
<zmike>
sounds like maybe something to bisect
<pac85>
Yeah, I'll keep this in mind if you can't reproduce. I get 300 fps on mesa from the distro while I only get 90 with the one compiled from the main branch (and it chugs pretty badly sometimes looking at the trace playing)
<zmike>
odd
<zmike>
replays fast enough here that I have to use min-frame-duration to see anything
<pac85>
bisect points at 3ed141e9d80 glthread: add a heuristic to stop locking global mutexes with multiple contexts
<pac85>
And I can confirm that the commit before it is fine
<zmike>
interesting
<zmike>
probably worth raising a ticket
<pac85>
yeah, I'm seeing if it affects radeonsi, then I'll open an issue
<anholt>
disabling the slow linking path doesn't seem to be helping reproduce it, at least on my local adl. (disabling /* trigger async optimized pipeline compile if this was the fast-linked unoptimized pipeline */)
<zmike>
try MESA_SHADER_CACHE_DISABLE ?
<anholt>
same
<zmike>
ZINK_DEBUG=sync ?
<anholt>
are you suggesting that as a way to avoid the bug, or a way to reproduce?
<zmike>
I'm wondering if it has any effect
<anholt>
that would be a couple hours to test
<anholt>
was going to zink_debug=validation it, but vvl is crashing at /home/anholt/src/prefix/lib/libVkLayer_khronos_validation.so: _ZN17RENDER_PASS_STATEC2EPK29VkPipelineRenderingCreateInfob+0x177bc1a render_pass_state.cpp:301
<zmike>
hm that looks like something that was fixed in the latest tag
<zmike>
or should've been
<anholt>
I am, in theory, running the latest tag
<zmike>
ugh
<zmike>
crashes here too
<zmike>
will report again...
<anholt>
anyway, not sure I can contain many more thoughts today. going to leave this pipeline cache stress run going.
<zmike>
how often were you seeing this trace flake in your runs? rough %
<zmike>
doesn't seem like I can repro on icl, at least
<anholt>
15%
<anholt>
not this specific trace, freedoom was high on the list, and I think a valve trace too
<zmike>
just ran this one a couple dozen times locally and didn't see the issue
<anholt>
probably should start from a clean cache, if you aren't
<anholt>
(trying to mimic ci environment better)
<anholt>
but then there's a bunch of other load on the system from the other traces running in parallel
<zmike>
🤔
<zmike>
cache doesn't seem to affect it one way or another
<zmike>
I'm pretty fried today, but so far I haven't been able to repro on icl or dg2