On Sat, Nov 19, 2016 at 1:13 AM, Tom Stellard <t...@stellard.net> wrote: > On Sat, Nov 19, 2016 at 01:09:00AM +0100, Marek Olšák wrote: >> On Wed, Nov 16, 2016 at 4:38 PM, Tom Stellard <t...@stellard.net> wrote: >> > On Wed, Nov 16, 2016 at 11:13:45AM +0100, Nicolai Hähnle wrote: >> >> Have you looked at the shader-db impact? >> >> >> > >> > shader-db is mostly unchanged. There are a few decreases in SGPR usage and >> > code size, and a 4 byte increase in code size for one shader. >> > >> >> I do think we should eventually do this, but llvm.SI.vs.load.input is >> >> ReadNone while llvm.amdgcn.buffer.load.* is only ReadOnly, so as long as >> >> we >> >> can't teach LLVM properly about no-aliasing and speculability, there may >> >> be >> >> performance regressions. >> >> >> > >> > Ideally llvm.amdgcn.buffer.load.* would be ReadOnly and ArgMemOnly, but I >> > think >> > as long as it has non-pointer arguments this combination behaves the same >> > as >> > ReadNone, which would be incorrect. >> >> Why would it be incorrect? >> > > Because llvm.amdgcn.buffer.load.* can be used in a lot of different > ways, so it is possible that the memory it is reading from has been > modified by the shader.
OpenGL tells us which buffers read from invariant memory and which aren't. We have most of the information from OpenGL or GLSL to tell whether a load or store affects any other buffers or not. E.g. a shader buffer or image with the "restrict" modifier means that its memory doesn't overlap with any other buffer. Read-only buffers such as vertex buffers and uniform buffers have this property naturally. If you see only loads with that modifier, you can set ReadNone. If you see only stores with that modifer, you can set InaccessibleMemOnly I think. I would say that it would be more common in OpenGL to see llvm.amdgcn.buffer.load.* with ReadNone than ReadOnly if we used the LLVM attributes more aggressively. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
