[Mesa-dev] TGSI thoughts

[Jakob Bornecrantz]

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.

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.

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.

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.

Cheers Jakob.