On Tue, Jul 27, 2010 at 8:57 PM, Jakob Bornecrantz <wallbra...@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 <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
