ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
omegatron has quit [Quit: What happened? You quit!]
Akari has quit [Remote host closed the connection]
Akari has joined #zink
omegatron has joined #zink
<jekstrand> zmike: For those copy_prop_vars fails, is it copy_prop_vars in lavapipe that's the problem?
<zmike> no
<jekstrand> st_mesa?
<zmike> that MR adds usage in zink
<zmike> which is why it only fails there
<jekstrand> ah
<zmike> also I addressed your dmabuf concerns
<jekstrand> uh... It's failing on main, not just your MR
<zmike> I can confirm that it is not failing on main
<jekstrand> zink+lvp is failing for me
<zmike> LIBGL_ALWAYS_SOFTWARE=1 MESA_LOADER_DRIVER_OVERRIDE=zink bin/shader_runner /home/zmike/src/piglit/tests/spec/arb_arrays_of_arrays/execution/atomic_counters/fs-indirect-index.shader_test -auto -fbo -> PIGLIT: {"result": "pass" }
<zmike> on ee1a0a0772d0aaf4f5124d451f6a087bc6910b58
<jekstrand> Doesn't LIBGL_ALWAYS_SOFTWARE force llvmpipe, not zink?
<zmike> no
<zmike> not if you specify zink as the driver
<zmike> zink won't use lavapipe without it
<jekstrand> Oh, well I specify lavapipe differently. :-/
<zmike> you can specify it however you want, but without that you're not getting it
<jekstrand> I wonder what driver I'm getting then. :joy:
<jekstrand> Looks like llvmpipe just straight-up fails the same test....
<jekstrand> woo!
<zmike> could be for the same reason? might get a twofer by fixing this
<jekstrand> One can hope!
<jekstrand> Ugh... Atomic counters really need to be their own variable mode.
<jekstrand> I had a patch somewhere for that
<jekstrand> zmike: What MR should I be looking at? It's hard to get there from a CI fail.
<zmike> also though if you look in the middle of the page on the right side it shows the MR
<jekstrand> zmike: 90% sure it's a zink bug
<jekstrand> zmike: What's happening is that somewhere along the line, zink has some stuff on an SSBO using ssbo_atomic_* intrinscs and other stuff using derefs. This isn't going to work.
<zmike> jekstrand: rephrase?
<jekstrand> It's the same SSBO. The one used for atomics by nir_lower_atomics_to_ssbo. But there's both load/store_deref acting on it and ssbo_atomic_inc acting on it.
<jekstrand> It's like someone ran lower_io but only for atomics
<zmike> ah, this is hitting one of my TODOs
<zmike> so you're saying the optimization pass doesn't handle this
<jekstrand> No
<jekstrand> We could make it detect ANY SSBO intrinsic and just throw up it's hands.
<jekstrand> But right now it assumes that any given buffer will only be touched through "direct" intrinsics or only touched through derefs.
<jekstrand> Which is a reasonable assumption for all non-Zink drivers.
<jekstrand> zmike: What TODO is this?
<zmike> /* TODO: these should all be rewritten to use deref intrinsics */
<zmike> in zink_compiler.c
<jekstrand> hehe. Yeah, that'll do it. :)
<zmike> grimace
* jekstrand adds another tick on his side of the chart
<jekstrand> :P
<zmike> whoa whoa whoa hold on
<zmike> I don't think this one's clearly in your favor
<zmike> at best you've got a tie
<jekstrand> How do you figure?
<zmike> I don't see a reason why the optimization pass shouldn't be able to handle this
<zmike> sure, ideally I'll get around to fixing the TODO on my side, but the pass should handle all possible cases
<jekstrand> It handles all reasonable cases from the assumption that you start with high-level stuff and lower.
<jekstrand> You're going backwards from low-level to high-level and doing it incompletely. I think it's perfectly reasonable that no one thought to account for that.
<jekstrand> :D
Akari has quit [Read error: Connection reset by peer]
Akari has joined #zink
kchibisov_ has quit [Ping timeout: 480 seconds]
eukara_ has joined #zink
eukara has quit [Read error: Connection reset by peer]