[Mesa-dev] [PATCH 2/2] radeonsi: Use buffer_load intrinsics instead of llvm.SI.vs.load.input
Marek Olšák
maraeo at gmail.com
Sat Nov 19 01:16:07 UTC 2016
On Sat, Nov 19, 2016 at 1:13 AM, Tom Stellard <tom at 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 <tom at 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
More information about the mesa-dev
mailing list