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

[Eric Anholt]

On Wed, 28 Jul 2010 11:23:59 +0100, Keith Whitwell <keithw at vmware.com> wrote:
> 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.

The way you'd do that is to do exactly what we've done: Write a
translation from your new compiler's IR to the current IR so you can
bring it up on drivers.  Our intention is for glsl2's IR to be the new
IR that drivers use.  As compared to mesa IR, it's got types, it's got
expression trees, and it's wicked easy to transform.  Writing most of my
passes has taken about a day to make existing testcases work.  Compare
to the misery of trying to do something as conceptually simple as copy
propagation on Mesa IR.

Of course, the next step after building the better IR is to convert old
frontends to it, and then to get drivers to use it so that they get the
advantages of it.  We do plan on converting the frontends.  I'm also
hoping to get to a 965 fragment shader backend before other work
scheduling pwns me -- not supporting arrays in GLSL is bogus, but
they're pretty much intractable under Mesa IR.

And, of course, the fact that the compiler produces a particular IR
doesn't mean that's what you need to be operating on it in your driver's
backend.  965 non-GLSL FPs and radeon both convert to a driver-internal
IR today, and while at least 965's operations on the internal IR are not
particularly advanced, it is a normal thing for a compiler backend to do
and it doesn't necessarily reflect badly on the compiler's mid-level IR.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100730/7fd4cba4/attachment.pgp>