Hi Nicolai,
Thanks for taking over this work and going the whole nine yards with it!
This series is, Reviewed-by: Edward O'Callaghan
<[email protected]>
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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
