[Mesa-dev] TGSI thoughts

Brian Paul brianp at vmware.com
Wed Jul 28 07:39:51 PDT 2010


On 07/28/2010 08:25 AM, Zack Rusin wrote:
> On Wednesday 28 July 2010 06:26:39 Marek Olšák wrote:
>> Going from GL2.1 to GL1.5 just because some hardware can't do ddx and ddy
>> seems a bit silly to me.
>
> I'm not quite sure what do you mean here, derivatives have been present in
> GLSL since 1.1 so realistically hardware without them can't support any
> version of GLSL.
>
>> PS3.0 doesn't have address regs, that means there are no ARL/ARR/ARA
>> opcodes. Are you sure these must be mandatory? Please see:
>> http://msdn.microsoft.com/en-us/library/bb172920%28VS.85%29.aspx
>
> I was saying that they are mandatory for Gallium, not that semantically they
> are mandatory for everyone (also as Keith pointed out they are there in
> VS3.0). Long term, especially with GPGPU it would probably make sense to make
> our indirect addressing more robust but for now it is what it is.
>
>> PUSHA, POPA, and pack/unpack opcodes are not in SM3.0 either.
>
> Like I said the pack/unpack are probably least useful from the list and kept
> largely for the "we might need them one day" reason. I don't think anyone
> would miss those but since no one really even touches them they don't seem to
> bother anyone badly enough to do something about it.

Specifically, if someone really wanted to implement the NV-flavored 
vertex/fragment program extensions with a Gallium driver (namely the 
NV gallium drivers) some of these TGSI opcodes would come into play.

BTW, src/mesa/program/prog_instruction.h has a table of sorts 
indicating which Mesa opcodes (and by extension, which TGSI opcodes) 
are used by each of the vertex/fragment program extensions and GLSL.

-Brian


More information about the mesa-dev mailing list