<zmike>
what was going on with that 16bit shared load/store thing, and is there anything I can jump in on to help out?
<anholt>
I would love some help there, I really don't get how you're remapping things for ubo/ssbos to reuse that for shared.
<zmike>
ok, if you want to point me at a test case I can get that cleaned up when I get home in a bit
<anholt>
and we can't merge the mesa side of 16-bit shared until that's fixed, unless we add Yet Another Cap
<zmike>
sure
<anholt>
looks like dEQP-GLES31.functional.compute.shared_var.basic_type.ivec3_lowp was an example
<zmike>
on main?
<zmike>
or some MR branch
<anholt>
mediump-vars-gl of my tree
<zmike>
got it
<zmike>
will ping you when it's done
<anholt>
my zink change there is bogus, ignore it
<zmike>
👍
<zmike>
will probably be an hour or so until I'm home anyway
<zmike>
anholt: I think I've got it done, but there's a weirdness with the mediump cases: in e.g., dEQP-GLES31.functional.compute.shared_var.atomic.exchange.mediump_int the shared block size is 2, but it's still trying to do a 32bit shared_atomic_exchange
<anholt>
Oh, hmm. I'm surprised atomic is even allowed on mediump ints.
<zmike>
it's a weird one
<anholt>
I think nir_lower_mediump_vars needs to just walk the instrs first to scan the set of variables used for atomics, and then bail on try_lower_mediump_var() on them.