[Mesa-dev] TGSI thoughts

[Corbin Simpson]

On Tue, Jul 27, 2010 at 8:57 PM, Jakob Bornecrantz <wallbraker at gmail.com> wrote:
> Hi all
>
> So I was reading up on TGSI and noticed somethings that I thought
> could use some improvements, also please excuse any ignorance on my
> part I'm pretty new to low level shader stuff:
>
> 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.

Yes. There's lots of TBD in the TGSI spec, and we never discussed it.

> I remember there being some resistance to adding more pipe caps to
> Gallium because of added complexity to the state trackers. I wondering
> if we can use the u_cap code to create meta caps that the state
> tracker would use to se if a feature like GLSL would be supported by
> the hardware, alternatively the driver would just hock up the glsl cap
> into the same u_cap callback and give itself as an argument. Corbin
> have already added the needed limits for SM2 and SM3, just adding the
> caps for the extra caps for the other features should be easy. The
> added advantage of this is that people can look at the actual used
> code to see what they need to implement for a given feature and not
> documentation which never gets updated.

That might be nice. Updating the docs would totally be possible, too,
especially if people tell me where the docs suck the most.

> 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.
>
> For some instructions the documentation is missing, for example IF,
> ELSE, ENDIF and all the texture lookup instructions. I could gather
> some from the headers and tgsi_info, but filling out the documentation
> would be nice. Not listed are those I mention below in the considered
> for removal list.
>
> 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. When I say not plumbed to Gallium I mean
> not implemented by the mesa state tracker.
>
> UP2H, UP2US, UP4B, UP4UB, PK2H, PK2US, PK4B, PK4UB: Unpack and Pack
> various types into and out of registers. There seems to be support for
> these in the Mesa frontend but these haven't been piped into gallium,
> nor is any driver implementing them. Maybe just move them out of core?
> No documentation.
>
> PUSHA, POPA: Push a temporary on the stack. Not plumbed to Gallium, no
> driver implement them.
>
> BRA: Unconditional jump without return. Seems to be supported by the
> nv50 and i965g driver, probably supported by other hardware as well.
>
> ARA: Address Register Add, no documentation, just "src.x++" or
> "round(src0.x) + round(src1.x)"? Not plumbed to Gallium, no driver
> implement it.
>
> ARL, ARR: Address register load, with either floor or round, just use
> floor and round?
>
> X2D: 2D Coordinate Transform, looks like something that hardware
> doesn't natively support but instead always expand to some other
> operations. Not plumbed into Gallium, no driver implement it.

This should be expanded.

> RFL: Reflection Vector, This a lot more complex then X2D and from the
> looks of it is supported natively on the nv30. Not plumbed into
> Gallium, no driver implement it.
>
> SFL, STR: Set on True/False, sets dst to either 0 or 1. Not plumbed to
> Gallium, no driver implement them.

This should be expanded too.

In terms of TGSI-generic optimizations, I think the first thing should
be instruction lowering, since (nearly) everybody needs it anyway for
some things.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>