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

[Marek Olšák]

On Tue, Mar 22, 2016 at 12:21 AM, Nicolai Hähnle  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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[eocallaghan]

Hi Nicolai,

Thanks for taking over this work and going the whole nine yards with it!

This series is, Reviewed-by: Edward O'Callaghan 



Thanks again,
Edward.

On 2016-03-22 10:21, Nicolai Hähnle 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.

Please review!

Thanks,
Nicolai

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Nicolai Hähnle]

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.

Please review!

Thanks,
Nicolai

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev