Radeon R300 Driver Lands NIR-To-TGSI Code, Old NVIDIA Driver Eyes It Too

[phoronix]

Phoronix: Radeon R300 Driver Lands NIR-To-TGSI Code, Old NVIDIA Driver Eyes It Too

The open-source Radeon Linux graphics driver work covered yesterday about a big optimization by leveraging NIR and going through that intermediate representation and relying on common NIR optimizations has now been merged into Mesa 22.0. This is a step-up from the existing open-source OpenGL driver support for old Radeon 9500 through Radeon X1000 series (R500) graphics processors. A similar conversion is also planned for the old Nouveau driver handling NVIDIA "NV30" era graphics processors too...

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-22.0-Lands-R300g-NIR-TGSI

[Azpegath]

Could it be beneficial to always translate the GLSL to SPIR-V before continuing the conversion to NIR and onwards?
And run an optimization pass on the SPIR-V state? Mainly to have the same type of steps for Vulkan as well as OpenGL (4.5 as well as older).

[oiaohm]

Could it be beneficial to always translate the GLSL to SPIR-V before continuing the conversion to NIR and onwards?
And run an optimization pass on the SPIR-V state? Mainly to have the same type of steps for Vulkan as well as OpenGL (4.5 as well as older).

The answer to this is most no. Zink uses NIR for a reason because NIR designed for the GLSL IR problem..

http://www.jlekstrand.net/jason/projects/mesa/nir-notes/

Yes NIR or long form "new IR (internal representation)" is in fact design to sit between GLSL IR and what every backend you are using.

NIR can backend to TGSI, llvm iR, SPIR-V and direct nir supporting backend compliers.

SPIR-V backends to NIR and llvm IR inside mesa. Yes outside mesa you find things like SPIR-V cross and so on that will backend to more options including GLSL IR but this does not mean it going to be a good idea.

Yes NIR due to being design to support GLSL IR is design to validate GLSL IR that the input IR was in fact valid. So attempting to make a GLSL to SPIR-V you would end up mostly remaking NIR by some means if you don't use NIR and also possible have to remake the optimisations in the NIR system.

Think about this you are on some hardware that direct to hardware compiler can take NIR then GLSL to SPIR-V bit is NIR or not is going to have about the same overhead then you have to covert from SPIR-V back to NIR. The hardware that direct NIR will be weaker hardware so this overhead will hurt more.

The reality is NIR to TGSI is getting rid of the old not optimised GLSL-IR to TGSI where it was attempt at a direct step from GLSL-IR to TGSI. Having a correct internal representation designed to optimise and validate GLSL-IR is giving speed improvements.

The question is after the NIR to TGSI conversions are done so converting over the upper levels will it be possible to port over the TGSI complier to native to NIR so removing TGSI from the mix. Like R600 is on the process of moving over to NIR completely doing away with TGSI and other drivers in mesa have been progressively dropping TGSI.

So its not GLSL to SPIR-V I see as item that need to happen. TGSI being done away with is something I see that should happen to reduce the number of internal representations mesa has.

SPIR-V does not have the ability to store the meta data for direct to hardware this is why you have to go from SPIR-V to NIR or llvm IR before getting to hardware under mesa.

Yes SPIR-V to direct TGSI does not work so that had to be SPIR-V to GLSL IR to TGSI with poor optimisations before this change.

[darkbasic]

What about ACO for radeonsi? Did the work stall?

[smitty3268]

What about ACO for radeonsi? Did the work stall?

That was always a long-term plan. Work continues to align more radeonsi and radv code in order to simplify this in the future, but there was never any rush to any of that.

In the short term, Valve devs are busy optimizing radv and getting it ready for the Steam Deck launch next year, and getting newer hardware features like raytracing and mesh shaders working.