[Mesa-dev] GLSL IR to TGSI translator

[Bryan Cain]

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.

Bryan