[Mesa-dev] [PATCH 00/11] radeonsi: shader buffer support (atomic counters, ssbo)

Marek Olšák maraeo at gmail.com
Tue Mar 22 18:43:14 UTC 2016


On Tue, Mar 22, 2016 at 12:21 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> Hi,
>
> since shader images have laid most of the foundation, here are shader buffers
> now. This is the last extension missing for OpenGL 4.2 (we still need to turn
> on GLSL 4.2, but I think that only involves flipping a bit).
>
> As with shader images, this extension needs bleeding edge LLVM - this time,
> important patches have not landed upstream yet, and if you want to try this
> code you'll need my LLVM branch at https://cgit.freedesktop.org/~nh/llvm/log/?h=images
>
> (For those following along at home, the necessary LLVM patches for shader
> images have already landed upstream.)
>
> In principle, there are two alternative implementations for shader buffers:
> using LLVM IR  pointers with LLVM-native load/store instructions directly, or
> using intrinsics that operate on GCN buffer descriptors. This implementation
> uses the second approach. A brief comparison between the two approaches:
>
> 1. The pointer approach would use FLAT memory instructions on CI+, which
>    operate on 64 bit pointers rather than 128 bit buffer descriptors. This
>    would reduce SGPR memory pressure slightly.
>
> 2. LLVM understands pointers for alias analysis, so it's possible that it
>    would generate somewhat better code if we were to use pointers in the
>    IR.
>
> 3. The buffer load/store intructions have built-in bounds checks. Bounds
>    checks are required for an honest implementation of the ARB_robustness
>    extension, which we claim to support.
>
> The last point makes it obvious that the implementation really needs to use
> buffer intrinsics, but it'd be interesting to know how big the difference
> in code quality is versus something that uses pointers. To get the best of
> both worlds, we should really find a way to teach LLVM's alias analysis
> about what those buffer descriptors mean. For now, this current approach is
> the right way to do it.

Using 64-bit pointers is annoying from the radeonsi perspective,
because it requires a shader key bit that determines whether to use
the pointers. I've tried to implement it for constant buffers, but the
improvement in code quality was negligible and the added code
complexity and shader variant totally weren't worth it.

Marek


More information about the mesa-dev mailing list