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!]
<ajax> zmike: doing some test runs of the compute pbo branch
<ajax> pro tip: if you only want to see baselines and regressions. pbobench | grep -vF '[1;32'
<zmike> ooo
<zmike> ajax: how's it looking?
<ajax> mixed bag?
<ajax> writing up some results to post on the mr, i think i see some patterns
<ajax> and i'd like to run this again against at least my radeon and maybe my zinkvidia
<zmike> you doing cs only or just default?
<ajax> main vs 11984 rebased atop it
<ajax> at least for skl it looks like your heuristics are making pretty good choices
<zmike> nice
<zmike> I forgot to add the size check like I mentioned in the ticket
<zmike> I think also though there's some profiling that could be done with stuff like swappixels on gfx vs compute since the compute path can do that in the shader vs gfx having to do it on cpu
<zmike> not sure how worthwhile that is since I've never seen swappixels actually used in the wild, but...
<ajax> to answer your question: env var?
<zmike> yeah, I'm running it here now
<zmike> I added an env var to override the default path for extended testing
<ajax> that was just build main, test, build the branch, test. i didn't set anything else
<zmike> MESA_COMPUTE_PBO=1 on that branch will force it to use compute over blit
<zmike> I'm trying to figure out a heuristic to use memcpy for those other cases you listed
<ajax> i'll give that a run, see if there's anywhere else we outperform
<zmike> I updated again now with the size clamping
<zmike> so for the default case all that should be left is figuring out how to block or fix the remaining formats that are worse
<ajax> compute seems to be pretty consistently faster for three-channel formats
<zmike> it's interesting that compute is massively faster for lots of cases on intel but not nearly as many on amd
<zmike> wonder if radeonsi is just worse at optimizing that huge shader somehow
<ajax> hah, maybe
<ajax> might be a good candidate for shader-db
<zmike> can shader-db do nir shaders?
<ajax> no idea. if it can't, maybe it should, if this kind of thing is going to be a thing
<zmike> not entirely sure how it'd be able to pass that to a driver though
<zmike> maybe a jekstrand question
<ajax> well. can shader-db do spirv, because if it can, nir_to_spirv
<zmike> eh you're kinda not getting the same thing after zink mangles the spirv though
<zmike> I guess I could just write a glsl version
<zmike> probably easier than nir
<ajax> 1,GL_R32F GL_FLOAT, 32x32, 1, 100.0%
<ajax> 2,GL_RGBA8 GL_UNSIGNED_BYTE, 32x32, 152682, 11860035.3%
<ajax> man, compiling that shader for the first time is rough
<jekstrand> zmike: What's the question?