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 <bri...@vmware.com >> <mailto:bri...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev