[Mesa-dev] TGSI thoughts

[Jakob Bornecrantz]

On Tue, Jul 27, 2010 at 10:25 PM, Zack Rusin <zackr at vmware.com> wrote:
> On Tuesday 27 July 2010 23:57:17 Jakob Bornecrantz wrote:
>> First off, the Core TGSI instruction set includes a lot of
>> instructions that not necessary all hardware can handle foremost off
>> these are DDX and DDY which should either be moved to the GLSL cap or
>> get a cap of its own. Related to this is IF and friends, tho this can
>> be handled by a compiler or optimizer but sometimes this might be
>> better to tell the higher levels about it so maybe a cap or some sort
>> of cap hint? And while on branching instructions the CAL and RET
>> opcodes could also do with the same treatment.
>
> We already have PIPE_CAP_GLSL. Or are you saying that you'd like to keep
> support for GLSL but not for those features? Personally I don't think that
> would make a lot of sense (you'll never be able to pass actual conformance on
> anything like that).

What I was trying to say is that at least according to the docs all
these instructions are in the Core TGSI set and must be available in
all drivers. Obviously they are not, especially DDX and DDY which are
quite magical.

>
>> Something that came up while planning for the tgsi optimizer and I'm
>> currently ignoring is source indirection (not texture). Indirection in
>> general isn't all that well explained in the documentation and I'm
>> wondering if it is available on all hardware or if it should be
>> protected be a cap. It is particularly challenging for the optimizer
>> if used to indirect a temporary read, since basically you then have to
>> treat all temporaries at that point as a array and it thus makes it a
>> lot harder to reshuffle and reallocate temporaries in such a shader.
>
> Gallium already supports a feature which fixes it - indexable temporary arrays
> (TEMPX register file). Mesa's state tracker just doesn't use it yet.

Ah cool I was wondering about that. Need to add some documentation
about that tho.

>
>> Going on there is a bunch of opcodes in core that are considered for
>> removal, most of them are never used by the state trackers or
>> implemented by any driver.
>
> TBH I don't think we have many (if any) opcodes anymore that we should be
> removing. TGSI is a bit different than the rest of Gallium - it's supposed to
> be a super-set of shader opcodes or more precisely be as expressive as
> possible to get the optimal translation from the original language. Besides
> the pack instructions that rest is actually very useful (and the ARL/ARR are
> absolutely mandatory, they're not at all like FLR/ROUND, since those are the
> only instructions that we allow to write to the address register).

Ah, I didn't know that about ARL/ARR/ADA, this makes sense, again
lacking some documentation (tho I could have read up about it in
ARB_vertex_program).

Cheers Jakob.