[Mesa-dev] GLSL IR to TGSI translator

[Eric Anholt]

On Mon, 02 May 2011 16:44:21 -0500, Bryan Cain <bryancain3 at gmail.com> wrote:
> On 05/02/2011 11:55 AM, Ian Romanick wrote:
> > On 04/27/2011 08:23 PM, Brian Paul wrote:
> > > On Tue, Apr 26, 2011 at 12:26 AM, Bryan Cain <bryancain3 at gmail.com>
> > wrote:
> > >> Hi,
> > >>
> > >> In the last week or so, I've been working on a direct translator from
> > >> GLSL IR to TGSI that does not go through Mesa IR.  Although it is still
> > >> a work in progress, it is now working and very usable.  So before I go
> > >> on, here is a link to the branch I've pushed to GitHub:
> > >>
> > >> https://github.com/Plombo/mesa/tree/glsl-130
> > >>
> > >> My main objective with this work is to make GLSL 1.30 support feasible
> > >> on Gallium drivers.  From what I understand, it would be difficult or
> > >> impossible to implement integer-specific opcodes such as shifting and
> > >> bit masking in Mesa IR, since it only supports floats.  TGSI, on the
> > >> other hand, doesn't have this problem, and already supports most or all
> > >> of the functionality required by GLSL 1.30.
> >
> > > Unfortunately, TGSI doesn't have everything we need yet.  There's
> > > opcodes for binary AND, OR, XOR, etc. and a few integer operations,
> > > but it's incomplete.  It shouldn't be a big deal to add what's missing
> > > but it'll take a little time.
> >
> > > I think everyone agrees that we want to eventually ditch Mesa's IR.  I
> > > _think_ that the only classic Mesa driver that uses Mesa IR and hasn't
> > > been deprecated by a Gallium driver, or already weaned from Mesa IR is
> > > swrast.  How much does the i965 driver still rely on swrast for
> > > fallbacks?  Do the Intel people see need for a GLSL IR executor for
> > > swrast?
> >
> > Right now i915, i965 (vertex shaders only), and r200 all use Mesa IR.
> > All of the non-shader chips also use it for vertex shaders.  We're in
> > the process of eliminating the use of Mesa IR in i965.  Mesa IR isn't a
> > horrible fit for i915 or r200.  Once everything else works directly from
> > GLSL IR, I'll probably evolve the use of Mesa IR to better match those
> > targets.  It will basically become a (semi-)shared low-level IR used
> > just by those drivers.
> >
> > I also need to finish changing the ARB_vertex_program (and friends)
> > assemblers to generate GLSL IR directly.  It's mostly done.  There's
> > really just a bunch of typing left.
> >
> > I don't think interpreter will go away from core Mesa any time soon.
> > We'll still need it for fallbacks on a variety of chips and vertex
> > shaders on non-shader GPUs.  That said, I don't think it needs to
> > support any of the new functionality.  The only classic driver that is
> > ever going to support 1.30+ is i965.  When we're on 1.30 shaders and
> > would need a full software fallback, I think we'll opt for
> > non-conformance instead.  I think there are only 3 or 4 places where we
> > hit software fallbacks, and I think we can take that ding.
> >
> > >> The translator started as a modified version of ir_to_mesa, and that
> > >> origin is still obvious from reading the code.  Many parts of
> > ir_to_mesa
> > >> are still untouched - glsl_to_tgsi is still a long way away from
> > >> eliminating all traces of Mesa IR.  It also contains a significant
> > >> amount of code adapted from st_mesa_to_tgsi, but modified to generate
> > >> TGSI code from the glsl_to_tgsi_instruction class instead of using Mesa
> > >> IR.  (It actually still generates Mesa IR instructions, but that could
> > >> be safely removed at some point since the generated Mesa IR
> > instructions
> > >> are not actually used for anything.)  I'm planning to push more of the
> > >> conversion to TGSI higher up in the stack in the future, although the
> > >> remaining remnants of Mesa IR (such as the Mesa IR opcodes used by most
> > >> of glsl_to_tgsi) aren't doing any harm.
> >
> > > I finally found a little time to look over your code.  As you said,
> > > it's basically a copy & paste of the ir_to_mesa.cpp and
> > > st_mesa_to_tgsi.c code at this time.  Do you plan to eliminate all
> > > remnants of Mesa IR there before adding support for GLSL 1.30?  One
> > > easy step would be to replace use of Mesa IR opcodes with TGSI opcodes
> > > and add new TGSI opcodes for integer ops.
> >
> > Mesa IR and TGSI are, structurally, very similar.  It seems like
> > starting with ir_to_mesa is the right plan.  That's how the i965
> > fragment shader backend was written, and it's how we're planning to do
> > the vertex shader backend.  At that point, it's better to change it to
> > generate TGSI instructions / opcodes instead of Mesa IR.  Once you get a
> > basic shader that moves a constant to the shader output working, it's
> > pretty much all downhill.
> >
> > There's a lot more typing before you have something that compiles, but
> > the overall route to the goal is much shorter.
> 
> Right, this is exactly why I started the way I did.  In fact, I've
> accomplished a lot in the week since I sent my initial message, and I
> recently finished replacing all of the Mesa IR opcodes with the
> equivalent TGSI opcodes, although I haven't pushed it to my public
> branch yet.  Everything is still working properly, too, except for a few
> regressed Piglit tests, and I think I know what's going wrong with them.
> 
> It's producing reasonably well-optimized code, too, often using
> considerably fewer temporaries than the Mesa IR path, although it still
> uses a few more instructions in most places.  The main things I still
> need to do are remove the remaining traces of Mesa IR (mainly the
> prog->Parameters and prog->Attributes lists at this point), translate
> the GLSL 1.30 operations for drivers that support them, and look into
> more optimization opportunities so that it can emit identical or better
> code than the Mesa IR path emits with the help of _mesa_optimize_program.

The biggest win I'm looking at right now in terms of instruction count
for i965's backends is making the assignment handler suggest to the
expression (or other) handlers where to store their results instead of
using temporary storage for this->result, but being able to recover if
they had to store to a temporary for unaliasing their registers.  This
takes a lot of pressure off of the copy propagation and register
coalescing passes in the backend as it means that there just aren't as
many gratuitous moves needing to be removed.

The code was pretty easy for the 965 fragment shader (about 60 loc,
waiting to measure a performance change to push it), but I expect it
will be trickier on vec4 architectures where you potentially have to
reswizzle arguments of expression opcodes according to the new
destination's writemasks.
-------------- 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/20110504/91eb8489/attachment.pgp>