[Mesa-dev] GLSL IR to TGSI translator

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2+4eYACgkQX1gOwKyEAw867ACffDYjv2+00nZFm+r+48v5Tnp9
5TsAnRae6IfR+BFlODN3th2Z1eEvnXWO
=J77N
-----END PGP SIGNATURE-----