RadeonSI May Eventually Switch To NIR Completely

RadeonSI developers have been working on supporting the NIR intermediate representation within their Gallium3D driver as a means to support ARB_gl_spirv for being able to load SPIR-V shaders in OpenGL and interact with the RADV Vulkan driver code paths, which is making use of NIR. It's looking like in the future the RadeonSI driver could end up using NIR completely by default.

At this point the NIR back-end for RadeonSI is considered experimental while RADV is using NIR as well as the Intel i965/ANV drivers, Freedreno, and VC4 too. With this experimental support, NIR with RadeonSI only handles OpenGL 3.1 and no real performance advantages yet over the existing code-paths.

In the discussion about plumbing 16-bit support in Gallium3D's TGSI, Marek commented to fellow AMD developer Nicolai Hähnle about using NIR "completely" to avoid having to add the 16-bit support to TGSI, since it's already in place for NIR.

Nicolai commented that the geometry and tessellation shaders still need to be done for RadeonSI NIR (and why it's at OpenGL 3.1 rather than GL 4.5) and there are some other NIR extensions still to be finished as well as bug fixing. He ended with, "There's a bunch of unknowns, so it's hard to say, but once we're there 16-bit should be much easier, so may be worth it."

The RadeonSI NIR backend is still going through LLVM for targeting the AMDGPU back-end in order to generate the hardware instructions, but going "all in" with using NIR could result in more code sharing with the Intel folks (among others) and will be interesting to see the other impact once the NIR back-end is more full-featured.