On Mon, Dec 14, 2015 at 8:03 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > On Mon, Dec 14, 2015 at 10:50 PM, Jason Ekstrand <ja...@jlekstrand.net> wrote: >> 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? > > 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).
Right. I don't actually know what we can do with our HW. I was mostly thinking about what optimization passes can or cannot do with a variable. It sounds like, whatever we do, you want it passed through somehow. How about we just add a little well-defined bitfield as an extra argument to the SSBO load/store intrinsics? The fact that it gets applied to a variable or a struct or a member or whatever is kind of a moot point to the backend compiler. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
