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

[Brian Paul]

On 06/22/2011 08:51 PM, Bryan Cain wrote:
> 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?

Currently, the extra fields in st_fragment_program are 'tgsi' and 
'variants'.  They only get set/used after the base program's 
translated into tgsi so they're not relevant in the drawpixels / 
pixeltransfer code.


> 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?

Can't you just replace gl_fragment_program with st_fragment_program in 
the drawpixels and pixeltransfer code?


> 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.

I'm kind of on the fence.  Does this bring some real value to the 7.11 
release?  Is there a downside to putting it in 7.12?

I'm going to be on vacation next week and may not be of much help if 
there's any problems.

-Brian