[Mesa-dev] SSBO + access qualifiers

[Jason Ekstrand]

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?
--Jason