[Mesa-dev] [PATCH] gallium: add PIPE_SHADER_CAP_SUBROUTINES

Brian Paul brianp at vmware.com
Mon Nov 22 08:13:19 PST 2010


On 11/22/2010 02:54 AM, Jose Fonseca wrote:
> I have no objection with the change FWIW.
>
> I agree that given that there is no shared compiler infrastructure for gallium drivers exposing the right capabilities to state tracker is the good compromise.
>
> Concerning replacing TGSI with something else, I've said it before, but it doesn't hurt re-state it: yes, it has become obvious that gallium needs a compiler insfrastructure, and I would have no objection with TGSI being replaced with GLSL IR or LLVM IR, provided that this IR is a superset of TGSI and the infrastructure as portable as gallium.
>
> That said, we have no immediate plans to carry such work. We'd be happy to provide feedback/assistance to anybody in the community though. LunarG already showed interest in developing LLVM IR, and although challenging the prospects of using LLVM is also enticing. Intel's focus so far has been in the Mesa classic, but if you/others want to look into GLSL2 in gallium it looks a worthy project as well.

[...]

Another little issue with a new gallium shader representation is 
shader editing.

In the draw module (and in the state tracker) there's several places 
where we modify the incoming tokenized shaders.  For example, to draw 
AA points we modify the fragment shader to compute fragment coverage 
within a circle and do fragment culling.  In the state tracker we 
prepend a texture lookup to the current shader to implement glDrawPixels.

This is fairly straightforward with TGSI.  I haven't looked at how 
much work it'll be with the new tree-based IR.  I suspect it'll look 
like some of the GLSL lowering passes that have been doon.  Anyway, 
it's another thing to keep in mind.

-Brian


More information about the mesa-dev mailing list