[Mesa-dev] SSBO + access qualifiers

[Ilia Mirkin]

On Mon, Dec 14, 2015 at 10:50 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Mon, Dec 14, 2015 at 4:10 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Hello,
>>
>> I was going to add support for the various volatile/etc annotations in
>> my gallium impl (which is fairly far along), but it seems like those
>> are currently being dropped on the floor by lower_ubo_references, and
>> NIR has no support for them either. Both in GLSL IR and NIR, the
>> variable is what holds the access annotation (volatile, etc). However
>> the ssbo intrinsics are all about a particular binding and offset,
>> without any reference to the variable.
>>
>> What's the right way of handling this? (And do any tests exist that
>> would be sensitive to getting such things wrong?)
>
> First off, why is it that way?  Well, because most of the IRs in mesa
> don't have a memory model capable of handling these sorts of things.
> Those that do (LLVM is the only one I'm aware of) can't handle the GL
> packing rules.  The result is that we basically have to lower
> everything away to byte-offset load/store intrinsics.
>
> What do we do about it?  My inclination would be to either add two new
> intrinsics for load/store_ssbo_volatile or to add a new constant
> boolean "volatile" parameter to the current intrinsics.  If a
> load/store happens on a volatile things, you get the volatile version,
> otherwise you get the plane version.  Then backends can know that they
> are free to reorder, combine, etc. non-volatile load/store operations
> as per their memory model and the provided barriers.  If they
> encounter a volatile load/store, they can't do anything with it and
> just have to do the memory op.
>
> Is that reasonable?

Well, I don't really care much about the NIR-side of it, but I think
at the very least coherent and volatile need to be exposed. I don't
much care about restrict, that's a bit too fancy for me, but no harm
in passing it through. TBH I don't get the point of
readonly/writeonly. FWIW this is what the nvidia hw is capable of:
http://docs.nvidia.com/cuda/parallel-thread-execution/#cache-operators
(I know it's PTX, but the actual hw is basically the same.)

I think that volatile = cv, coherent = cg, and everything else = ca/cs
based on some clever heuristic (aka I'll always pick one of those
until a situation where that doesn't work well arises).

  -ilia