A Mesa Branch Provides GLSL IR To TGSI Translator

[Plombo]

Which apps/games look differently with your special mesa branch?

None that I know of. Hopefully none at all, since the behavior should stay the same.

How often do you update from mesa master?

I plan to merge it whenever there is something I need to adapt my code to, or once every week or two otherwise. Basically, whenever I need to so that my branch doesn't fall significantly behind master.

Should games run faster?

Short answer: no.

Long answer:
Not really. Conversion from Mesa IR to TGSI doesn't have much effect on the quality of the shader code since the instructions have an almost 1:1 correspondence.

In theory, it should actually be a bit slower currently since _mesa_optimize_program is no longer used, and my optimization passes which replace it are less advanced. However, I have yet to find a program in which there is any noticeable difference in performance, at least with the nv50 driver.

[Plombo]

I should amend my last answer. Although there are no performance improvements yet as far as I know, there will likely be a few improvements as the translator progresses. Some code which was being emitted after the optimization passes can be pushed up to a slightly higher level so that the copy propagation, dead code elimination, and register consolidation passes can be run on it. I have no idea whether it will be significant; we'll just have to see once I get there.

[oibaf]

Wow, I just spent several hours of my life tracking down the issue with the Nexuiz title screen and the 0 A.D. water (same issue), and the patch that finally fixed it is a whopping 13 lines long.

0 A.D. confirmed fixed.

I plan to merge it whenever there is something I need to adapt my code to, or once every week or two otherwise. Basically, whenever I need to so that my branch doesn't fall significantly behind master.

What still do you plan to add before submitting it for mainline inclusion?

[Drago]

Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?

[bridgman]

Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?

My impression was that no decisions had been made yet; state trackers are still being written to use TGSI, Intel still intends to try generating HW instructions directly from GLSL IR rather than Mesa IR, and work is still proceeding on LunarGLASS. I guess the open questions are (a) whether GLSL IR will turn out to be a good fit for compute-type operations (eg OpenCL on GPU) and (b) how much of the existing LLVM optimizations LunarGLASS will be able to effectively leverage on GPUs.

There are probably important (c), (d) and (e) questions as well but I haven't had time to look at the IRs very much yet

AFAIK there was no expectation that proprietary drivers would be ported across to TGSI; the idea was simply to reflect the fact that for the last few years hardware had been designed more around DX requirements than around OpenGL requirements.

[Plombo]

What still do you plan to add before submitting it for mainline inclusion?

Well, it still has some remnants of Mesa IR even now. Most noticeably, the Mesa IR opcodes are still used instead of TGSI opcodes in glsl_to_tgsi_instruction. The parameter and attribute lists are also still stored in the format used by Mesa IR. I'll want to remove all of these Mesa IR remnants before submitting it for inclusion in master.

Also, the translator started out as basically a copy-paste (albeit heavily modified) of ir_to_mesa and st_mesa_to_tgsi. Although it's come a long way since then, some code in the TGSI generator (the part based on st_mesa_to_tgsi) should be pushed up into the GLSL IR translator (the part based on ir_to_mesa).

It'll also need a few other miscellaneous cleanups.

Nice work, indeed I had left with the impression, that TSGI will be dropped in flavour of GLSL IR. Since TSGI was invented because it is so close to direct3d internal represenation, and proprietary drivers will be just ported to TSGI from existing windows drivers. That didn't worked that way, so GLSL IR can be used for most convinience. Intel will be happy with it, I thing. What is your oppinion on this?

I hope that GLSL IR can be used directly by Gallium drivers and state trackers someday, at least as a cap (Gallium terminology) that drivers can enable if they support GLSL IR, so that it can be used instead of TGSI if both the driver and the state tracker support it.

With that said, though, it's much easier said than done. Gallium and the GLSL compiler were not designed to go together. The GLSL compiler follows OpenGL semantics, whereas Gallium uses a mix of Direct3D and OpenGL semantics. For example, as I understand it, Gallium has fairly strict rules regarding dependencies of pipe drivers; the GLSL compiler wasn't written with this in mind.

But if GLSL IR can make it into Gallium, I think it will be a huge win for drivers. Also, it won't make my GLSL to TGSI translator obsolete like you might think - it will probably just move out of the Mesa state tracker and become a Gallium auxiliary component as a transitional fallback for drivers that can't handle GLSL IR - softpipe comes to mind as a driver that would want to use it, since a GLSL IR interpreter would be cumbersome and a TGSI interpreter isn't.