On Mon, Dec 14, 2015 at 4:10 PM, Ilia Mirkin <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev