[Mesa-dev] TGSI thoughts

[Zack Rusin]

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).
 
> 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. 
 
> 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)

z