Gallium3D's Mesa State Tracker Sees Shaders Ported From TGSI To NIR For Capable Drivers

[phoronix]

Phoronix: Gallium3D's Mesa State Tracker Sees Shaders Ported From TGSI To NIR For Capable Drivers

Kenneth Graunke of Intel's Open-Source Technology Center team is the developer who has been leading the charge for the past year on developing the Intel "Iris" Gallium3D driver that eventually should succeed their "i965" classic Mesa driver for Broadwell hardware and newer. Today he issued a pull request for some improvements to Gallium3D's Mesa state tracker itself...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-ST-NIR-Native-Built-In-Sha

[Snaipersky]

I've had some difficulty looking for this, but does anyone know if gallium nine still needs TGSI, or is it NIR compatible? Should Intel come out with something akin to an APU (Iris graphics on a lower end CPU), it would be really attractive for building a HTPC whose duties would include wine games from the 00's.

[pal666]

I've had some difficulty looking for this, but does anyone know if gallium nine still needs TGSI, or is it NIR compatible?

i doubt anybody did switch it from tgsi to nir. there is no point, its backend is radeonsi, which isn't switched to nir yet

[Venemo]

I've had some difficulty looking for this, but does anyone know if gallium nine still needs TGSI, or is it NIR compatible? Should Intel come out with something akin to an APU (Iris graphics on a lower end CPU), it would be really attractive for building a HTPC whose duties would include wine games from the 00's.

Gallium Nine is traditionally TGSI-only. Since Intel didn't have a Gallium driver (and not many people play games on nouveau) there was no motivation to make it work with NIR. Now that we'll soon have an Intel Gallium driver (iris), this topic is becoming relevant.

There is a tgsi_to_nir converter, so in theory it's just a matter of hooking it up to nine. However in practice, this was not originally meant to be used with the kind of shaders nine has, so we'll have to patch it up first.

So, I hooked it up just to see what happens. It translates most shaders, but not all, and there are issues. What this means is some D3D9 games crash on start, while some of them can run, but will give you a black screen.

The next step is to figure out which shaders cause issues, look through them one by one and fix tgsi_to_nir to handle them correctly.

[benjamin545]

Or just convert it all to nir, if that would ultatly be the proper thing to do.

Is the plan for nir to replace tgsi as the unified ir for mesa? It is supose to have all the features needed to handle vulkan and opencl right?

It does kind of seem like it has been a mess in the past with IRs in mesa. Would be nice if everything kind of stuck to one.

[smitty3268]

Or just convert it all to nir, if that would ultatly be the proper thing to do.

It doesn't seem like that would be very difficult, either. I haven't really taken a look at the code, but IIRC it was doing some pretty simple translations from DX bytecode to TGSI instructions, wasn't it? Seems like NIR would be really easy to just drop in instead.

Is the plan for nir to replace tgsi as the unified ir for mesa? It is supose to have all the features needed to handle vulkan and opencl right?

It does kind of seem like it has been a mess in the past with IRs in mesa. Would be nice if everything kind of stuck to one.

I don't think VMWare has any intention of moving away from TGSI, so i suspect it will be around for quite a while even if all the hardware drivers end up moving to NIR.

R600 is questionable too. I know Gert Wollny has an experimental patchset trying to add NIR support, but that's likely a long way from completion and the different r600 hardware generations all seemed really finicky and full of poorly documented hardware bugs - meaning it's going to be tough for anyone to complete that driver without all the different hardware available for testing and time to fix it up. AMD certainly has no intention of spending any time on that driver anymore.

It does appear that all the new drivers are using NIR though, and drivers like radeonsi and nouveau will presumably switch over in order to gain GL 4.6 support at some point. Once that happens I think you can declare NIR essentially the new IR, and the holdouts are legacy drivers.

[benjamin545]

It does appear that all the new drivers are using NIR though, and drivers like radeonsi and nouveau will presumably switch over in order to gain GL 4.6 support at some point. Once that happens I think you can declare NIR essentially the new IR, and the holdouts are legacy drivers.

where does LLVM IR fit into all of this? i think the amd drivers are using it internaly for opencl and gallium has a LLVMpipe for a software backend suitable for opengl/openvg.

[Venemo]

Or just convert it all to nir, if that would ultatly be the proper thing to do.

D3D9 and TGSI are very similar, so D3D9 -> TGSI is a straightforward conversion. Thus, D3D9 -> NIR and TGSI -> NIR are of equivalent complexity. Since TGSI -> NIR already exists and works for some use cases, it seems to be easier to pick that up instead of reinventing the wheel. Whether it is better to just use NIR directly is a good question, and we're not sure.

Is the plan for nir to replace tgsi as the unified ir for mesa?

As far as I understand there are old drivers which use TGSI and there is no manpower or motivation to change them, and there are newer ones that support TGSI and don't plan to drop it. For instance, radeonsi works primarily with TGSI, and these days it supports NIR too, but it's not as mature as the TGSI code path, yet. There is some motivation to make all "modern drivers" switch over to NIR, but it's gonna be a long, long time before TGSI will disappear completely.

[mannerov]

It doesn't seem like that would be very difficult, either.

DX asm -> TGSI is a direct mapping, in the sense that we can just convert to TGSI instruction per instruction while we are reading the DX asm.
This is an extremely cheap pass compared to all that comes after during the compilation process (hw instruction selection, scheduling and register allocation being the most expensive passes).
Even if DX asm -> NIR was easy (which is probably not the case as NIR is more meant as an optimization IR), it wouldn't help the game speed. Compilation would be 0.01% faster, but then what ? Nine doesn't have stuttering and other issues because of shader recompilation, it doesn't need to save a few % of compilation time. Changes outside nine (in llvm for example) will affect compilation time significantly more.
TGSI is not going to be dropped, because of the reasons Venemo mentionned, even if maybe it might stop getting new advanced features at some point (but gallium nine doesn't need them).

Given DX asm-> TGSI is a direct mapping, it simplifies the code and maintenance to have DX asm -> TGSI and TGSI -> NIR done separately.
The DX asm-> TGSI code needs to do non-trivial things (even if direct mapping), for example an instruction might become three instructions, or depending on a d3d state it might need to be mapped to a different instruction or read a different input. It's probably better not to overcomplicate the code by not producing NIR directly if it isn't as direct as TGSI.

[andrebrait]

Where does SPIR-V get into all of this?