[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