[Mesa-dev] Status of the GLSL->TGSI translator

[Bryan Cain]

On 06/16/2011 12:43 PM, Brian Paul wrote:
> On 06/16/2011 10:34 AM, Bryan Cain wrote:
>> On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul <brianp at vmware.com
>> <mailto:brianp at vmware.com>> wrote:
>>
>>
>>     Looks like nice work, Bryan.
>>
>>     Just a few minor questions/comments for now:
>>
>>     1. The st_fragment/vertex/geometry_program structs now have a
>>     glsl_to_tgsi field.  I did a grep, but I couldn't find where that
>>     field is assigned.  Can you clue me in?
>>
>> It's assigned at the end of the get_mesa_program function in
>> st_glsl_to_tgsi.cpp.
>
> Thanks.  I was using grep glsl_to_tgsi *.[ch]   Duh.
>
>
>>     2. The above mentioned program structs contains an old Mesa
>>     instruction program AND/OR(?) a GLSL IR.  Do both types of
>>     representations co-exist sometimes?  Perhaps you could update the
>>     comments on those structs to explain that.
>>
>> They used to co-exist, because after my first commit, st_glsl_to_tgsi
>> still generated Mesa IR in addition to TGSI.  But I removed the Mesa
>> IR generation in "st/mesa: stop generating Mesa IR in
>> st_glsl_to_tgsi", so now it has either one or the other -
>> glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything
>> else.
>
> OK, can you update the comments with this info?
>
>
>>     3. Kind of a follow-on: for glDrawPixels and glBitmap we take the
>>     original program code (in Mesa form) and prepend extra
>>     instructions for fetching the fragment color or doing the fragment
>>     kill.  Do we always have the Mesa instructions for this?  It seems
>>     we don't normally want to generate Mesa instructions all the time
>>     but we still need them sometimes.
>>
>> No, I didn't realize Mesa did that, and we don't have the Mesa
>> instructions for GLSL programs anymore.  I'm not sure what the
>> right way to handle that is.
>
> How hard would it be to edit the IR to insert the extra operations?
>
> For glBitmaps it's basically sample a texture and then do a
> conditional fragment kill.  For glDrawPixels we need to sample the
> texture representing the image, then apply the pixel transfer ops
> (scale/bias, table lookup, etc).  We generate the code for that in
> st_atom_pixeltransfer.c.  That program is then concatenated with the
> current fragment program with _mesa_combine_program().
>
> If we ever propogate GLSL IR through the gallium interface there's
> lots of places where we'll need to do other kinds of IR editing.
>
> -Brian
>

I've been working on this for the last few days, but there are some
things I still haven't figured out yet.

I've written a function to generate the shader for
glDrawPixels/glCopyPixels in the form of glsl_to_tgsi_instructions, and
I doubt I'll have any problems writing the code to merge those
instructions with an existing shader.    However, for the shader to work
correctly, I need to set stfp->glsl_to_tgsi in st_fragment_program, but
all of the fragment program variables in st_atom_pixeltransfer.c and
st_cb_drawpixels.c have the type gl_program or gl_fragment_program. 
When do these become st_fragment_program so they can be processed in
st_program.c?  Will I need to move the glsl_to_tgsi attribute into
gl_fragment program and give it a name not specific to the state tracker?

My other question is that if I don't have this part done before the
merge window closes, would it still be possible to merge the GLSL->TGSI
translator for 7.11 tomorrow or Friday, and for me to fix the
glBitmap/glDrawPixels/glCopyPixels issue in the stable branch before
Mesa 7.11 is released?  It's the only remaining issue I know of with the
GLSL->TGSI translator, and even it's something of a corner case.

-Bryan