Intel Will Be Turning NIR On By Default In Their Mesa Driver

[phoronix]

Phoronix: Intel Will Be Turning NIR On By Default In Their Mesa Driver

Intel is planning to enable the NIR intermediate representation by default within their open-source Mesa Linux graphics driver...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-NIR-Default-Mesa-IR

[Drago]

Is there any performance gain to be expected?

[przemoli]

Is there any performance gain to be expected?

IR gpu driver works with directly influence which optimizations are easy and which are cheap (as in using least CPU time).

Ultimately its up to devs to implement those optimizations though, however NIR is used exactly for optimizations that are mad easier/cheaper by its design

[Veerappan]

Is there any performance gain to be expected?

Currently, they're trying to get NIR up to the same level as the current GLSL optimizations that are present in Mesa along with the optimizations that are done in the i965 back-end. The idea being that eventually the GLSL optimizer can be disabled in favor of NIR and many of the i965 specific optimizations would become redundant and could be removed (in favor of saving CPU cycles when compiling).

For the actual code executed on the GPU, they're currently working on achieving parity with the existing optimizations so that we don't see any major regressions in performance. In general, some shaders will be better, some may be worse, but overall they'll balance out.

Currently, i965 works something like:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizer -> GLSL IR-specific i965 backend -> i965 Back-end optimizations -> GPU Machine Code

Once NIR is enabled, it'll be:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizer -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> i965 Back-end optimizations -> GPU Machine Code

Then, they'll try to make the GLSL optimizations pointless:
GLSL Compiler Front-End -> GLSL IR -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> i965 Back-end optimizations -> GPU Machine Code

Then eliminate many of the i965 optimizations (although not all, since some will always be architecture specific):
GLSL Compiler Front-End -> GLSL IR -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> GPU Machine Code

And if things go well, maybe the GLSL compiler will be refactored to generate NIR directly:
GLSL Compiler Front-End -> NIR Optimizations -> i965 NIR backend -> GPU Machine Code

There's already a NIR to TGSI pass and I believe a TGSI to NIR translation pass, so there's no reason beyond testing/bug-fixing/filling-in-feature-gaps that the gallium drivers couldn't also use NIR.

Although that would make radeonsi look something like this for the short term:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizations -> Translate to NIR -> NIR Optimizations -> Translate to TGSI -> Hand off to radeonsi gallium driver -> Translate to LLVM IR -> LLVM Optimizations -> Generate AMDGPU machine code

Which is a bit icky.

[Veto]

Interesting comparison.

How does SPIR fit into all this? Can SPIR "rule them all" and provide a more direct path? Would it be feasible to so something like:

OpenGL:
GLSL Compiler Front-End -> SPIR Optimizations -> GPU SPIR backend -> GPU Machine Code

Vulkan:
SPIR Front-End -> SPIR Optimizations -> GPU SPIR backend -> GPU Machine Code

OR is SPIR on a higher abstraction level and requires translation to a lower level NIR/TGSI/LLWM IR?

Thanks,

[robclark]

Interesting comparison.

How does SPIR fit into all this? Can SPIR "rule them all" and provide a more direct path? Would it be feasible to so something like:

OpenGL:
GLSL Compiler Front-End -> SPIR Optimizations -> GPU SPIR backend -> GPU Machine Code

Vulkan:
SPIR Front-End -> SPIR Optimizations -> GPU SPIR backend -> GPU Machine Code

OR is SPIR on a higher abstraction level and requires translation to a lower level NIR/TGSI/LLWM IR?

Thanks,

I don't think you will really see SPIR->SPIR optimization passes (or TGSI->TGSI for that matter).. drivers will convert into NIR (or LLVM) which is easier to manipulate for optimization passes..

fwiw, I have a very basic/minimal NIR frontend for freedreno.. minimal == I only implemented enough opcodes for a handful of shaders, so it's not like it's going to land in master tomorrow or anything. But my long term plan is to use NIR for freedreno as well.

[geearf]

Currently, i965 works something like:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizer -> GLSL IR-specific i965 backend -> i965 Back-end optimizations -> GPU Machine Code

Once NIR is enabled, it'll be:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizer -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> i965 Back-end optimizations -> GPU Machine Code

Then, they'll try to make the GLSL optimizations pointless:
GLSL Compiler Front-End -> GLSL IR -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> i965 Back-end optimizations -> GPU Machine Code

Then eliminate many of the i965 optimizations (although not all, since some will always be architecture specific):
GLSL Compiler Front-End -> GLSL IR -> Translate to NIR -> NIR Optimizations -> i965 NIR backend -> GPU Machine Code

And if things go well, maybe the GLSL compiler will be refactored to generate NIR directly:
GLSL Compiler Front-End -> NIR Optimizations -> i965 NIR backend -> GPU Machine Code

Although that would make radeonsi look something like this for the short term:
GLSL Compiler Front-End -> GLSL IR -> GLSL Optimizations -> Translate to NIR -> NIR Optimizations -> Translate to TGSI -> Hand off to radeonsi gallium driver -> Translate to LLVM IR -> LLVM Optimizations -> Generate AMDGPU machine code

That was very interesting, thank you!

[jaxxed]

I don't think you will really see SPIR->SPIR optimization passes (or TGSI->TGSI for that matter).. drivers will convert into NIR (or LLVM) which is easier to manipulate for optimization passes..

fwiw, I have a very basic/minimal NIR frontend for freedreno.. minimal == I only implemented enough opcodes for a handful of shaders, so it's not like it's going to land in master tomorrow or anything. But my long term plan is to use NIR for freedreno as well.

Hey Rob, does that mean that the most likely path for mesa drivers will involve a SPIRV -> NIR conversion (seems that's what you're saying) and does that mean that a shared SPIRV->NIR compiler/converter is the likely path for Mesa drivers (if they get on board with NIR.)

While I am asking questions, is NIR going to allow Mesa/Gallium backends to share more OpenGL code, and require less custom driver specific OpenGL/Vulkan/OpenCL code?

[robclark]

Hey Rob, does that mean that the most likely path for mesa drivers will involve a SPIRV -> NIR conversion (seems that's what you're saying) and does that mean that a shared SPIRV->NIR compiler/converter is the likely path for Mesa drivers (if they get on board with NIR.)

While I am asking questions, is NIR going to allow Mesa/Gallium backends to share more OpenGL code, and require less custom driver specific OpenGL/Vulkan/OpenCL code?

tbh, having not seen the vulkan spec yet, it is a bit premature to speculate on the path towards vulkan.. although I expect there is room to share a spirv->nir pass, but the compiler is not completely independent to the rest of the state tracker state, and how that works out depends on details that those outside khronos (and perhaps inside khronos) don't know yet..

However that works out, I expect NIR will let us share some optimization passes (whatever makes sense for the given hw and backend/native IR).. for freedreno (and vc4 and pretty much every modern gpu), there are various cases where scalarizing in the driver (from tgsi, which is vec4 oriented to) can leave a mess that well known optimization passes can cleanup.. although no one wants to implement these passes in each different driver.. NIR provides an answer for that, which is why I'm interested in it. Nice thing about NIR is you can pick in the driver which optimization passes (if any) to run (so nouveau which already has a pretty mature compiler infrastructure could opt out of things that it already does in it's own backend, for example).