[Mesa-dev] TGSI thoughts

[Marek Olšák]

On Wed, Jul 28, 2010 at 7:25 AM, 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).
>

Going from GL2.1 to GL1.5 just because some hardware can't do ddx and ddy
seems a bit silly to me.


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

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

PUSHA, POPA, and pack/unpack opcodes are not in SM3.0 either.

Cheers.

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100728/39388716/attachment.html>