[Mesa-dev] Mesa-IR, TGSI and glsl2. [was Re: i965: merging the two compilation paths for fragment programs?]

[Keith Whitwell]

On Mon, 2010-07-26 at 16:50 -0700, Segovia, Benjamin wrote: 
> Hello all,
> 
> i965 has today an issue with fp compilation. There are two passes: one for branch-free programs and one for the others.
> 
> For "branch porograms", the code is generated by a _direct_ translation of the mesa gpu program. Even if with some optimizations in prog_optimize.c and the new upcoming compiler, it sounds clearly not enough. In particular, the mrf-to-grf move removes do not work and the better mov analysis (pass0, pass1, pass2 in i965 backend) done on the scalar code is not done at all if you have one branch.
> 
> What we need to unify all this is at least a control flow graph (cfg). The question is where to build it. 
> 
> glsl2 will have its own representation. Unfortunately, I imagine we can not use it in a short term for the back-ends since it means, breaking everything. 
> 
> So, maybe a simple strategy will be to have a cfg for each mesa program, cfg that can be built by the front end or by the back end if the front end did not provide it. Also, glsl2 could provide a cfg builder of its own from its own inner reprensation to the Mesa one (?)
> 
> So, what I plan to do right now as a proof of concept is to build a generic cfg (on _Mesa_ code not on Gen code) in the i965 back end and unify the i965 shader compilers using it. Then, if other back ends may use it, it could be fine to move it in the front end.
> 
> What do you think about that?

It seems clear that the next step after the glsl2-to-Mesa-IR work is to
plumb a more expressive shader representation down into the drivers and
use that to enable hardware-specific optimization.

In general I'd prefer to have an interface between mesa core and the
drivers which keeps the implementation of each hidden from the other.

Currently we have mesa-ir, which is semantically impoverished, but which
has (thankfully) acted as a fairly opaque interface to the current slang
compiler, and kept driver code independent of that codebase.

Although it's easy to spot the flaws of mesa-ir, it has given the nice
property that you've been able to innovate on one part of the stack
without breaking the rest.

Looking to the future, I'd like whatever comes to replace mesa-ir to
have a similar property of not exposing the inner workings of the GLSL
compiler to the drivers, and thus being able to retain the ability to do
independent development on either side of the interface.  

If ever we need to create glsl3, it would be nice if the drivers keep on
working across that transition.

And in addition, if the interface is designed properly, I think there's
a good opportunity here to take a look at TGSI and figure out if we
could create a single new semantically rich driver-IR which can be a
phased replacement for both Mesa-IR and TGSI.  

Keith