Mesa's IR Might Get Changed Around Amid Discussions

In a new mailing list thread, Eric Anholt expresses regrets a few years ago when they began sending GLSL IR into their driver rather than using Mesa IR and improving that intermediate representation. Eric is now trying to get the Mesa IR support up to scratch so that it can be sent directly to classic Mesa drivers.

Eric Anholt of Intel's Open-Source Technology Center wrote:

Here's a series I started back in January as a little experiment. Basically, I feel guilty for pushing GLSL IR into the driver, and wish I'd just fixed up Mesa IR back in the day. But, given that we're still feeding Mesa IR into drivers as well (ARB programs and fixed function vertex programs), it made me think: What if I fixed it up now, and got Mesa IR to the point that we could just garbage collect the GLSL IR input paths to drivers?

Mesa IR has a bunch of weaknesses that need to get sorted out if it's going to be useful:

- It's a single giant array of instructions, making modifications of the instruction stream (instruction lowering, optimization, etc.) more expensive in code and CPU time than it should be.
- It doesn't have any variable declarations, so if you have dynamic array indexing, optimization just shuts down (plus, no annotation on the temps, so debugging is irritating).
- It doesn't have integer instructions or anything else post-GLSL-1.30.
- The optimization passes for it are totally ad-hoc and fairly weak.
- It's not SSA.

I'm interested in fixing all of these. How do people feel about this goal?

This series fixes the first bullet point above. Patch 15 is huge, but I didn't see a way to chop it up smaller without maintaining the list alongside the array for some intermediate patches. I'd be willing to do so if needed, though, to make review doable. You can also find the changes in the "mesa-ir" branch of my git tree.

In response fellow Intel OTC developer Ian Romanick expressed concerns that this change would regress other old Mesa drivers like ATI R200 and the i915 drivers where they seldom see new work, testing, etc. It's also a bit like reinventing TGSI, the intermediate representation used by Gallium3D drivers. "I'm not very excited about exposing i915, r200, and swrast to more potential breakage that nobody will notice until 5 minutes before a release... or 5 mintues after. Not wanting to touch prog_exec is one of the reasons we avoided making changes to Mesa IR in the first place. It also feels a bit like a re-invention of TGSI, and nobody seems particularly enamored with that IR either. That said, it may still be an interesting experiment."

Open-source contributor Connor Abbott also expressed some reservations about the proposed change and 16 initial patches. "I don't know much about Mesa IR, but this seems like a huge pile of work... is this any easier than just making GLSL IR flatter, like with my flatland idea that I posted a while ago? Also, iirc, there was an effort a while ago to make ARB programs go through GLSL IR but it was abandoned - why was it so difficult? I'm skeptical that basically bringing an older IR from 1999 to 2014 is going to be less effort than modifying a newer one that had some good ideas and some bad ones."

Intel OTC developer Kenneth Graunke also expressed concerns. "I'm still really skeptical of this goal. I don't think reusing the existing Mesa IR backend code will save you much effort...Our Mesa IR adapters are missing features and have bad assumptions. For example, the VP code doesn't do texturing at all. The FP code assumes texture units/sampler units work like ARB programs. Neither do control flow at all. Neither do integer types. They also generate terrible code with piles of temporaries. You could fix all of these things, but it would entail writing a lot of code. And when you're done, you still have to throw the 'big switch' where you decide to use the new path instead of the GLSL IR path."

The discussion is still ongoing via this mailing list thread for those interested in GPU driver IR and Mesa.