[Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

[Luca Barbieri]

> There really needs to be a new TGSI semantic label for this.  The draw
> module needs some way to determine which fragment shader input expects PNTC.
>  Care to write a patch?
Actually, I'd propose using a GENERIC slot which is currently
unassigned, and using sprite_coord_enable to activate coord
replacement on it.
This seems simpler, since we need coordinate replacement anyway.

The really theoretically nice solution would be adding a new semantic,
and having a new linkage table that could be set to route writes to
that new semantics to reads from any GENERIC (for coord replacement).
However this is a massive change, and not necessarily good (i.e. it
might not match hardware well).

> I'm having trouble understanding what you mean there.
Suppose a vertex shader writes GENERIC[1],  GENERIC[2] and
GENERIC[60], and sprite_coord_enable is set to (1 << 1) | (1 << 2).

Draw will put sprite coordinates in GENERIC[2] and GENERIC[60],
because they are the 2nd and 3rd input written by the vertex shader.
r300g and nvfx will put sprite coordinates in GENERIC[1] and
GENERIC[2], because they are GENERICs number 1 and 2.
I'm not what mesa/st assumes (but clearly, it must be incompatible
with either draw or r300g).

Note that draw's interpretation has the flaw that it depends on the
vertex shader in a weird way, while r300g/nvfx's interpretation
prevents doing sprite coord replacement on GENERIC[32] and later
GENERICs.

There a lot of other subtle issues like this resulting from the
underspecification of how linkage is supposed to work.

IMHO the only way to fix it is to have someone with the authority to
decide take time to look at all API and hardware and formalize exactly
things like what is the range of allowed indices for the various
semantics, how sprite_coord_enable is to be interpreted and so on.

However, there is also the related issue that TGSI doesn't match
modern GPUs and GLSL, and switching to a new IR might heavily
influence the decision above (e.g. if we switch to LLVM bitcode for
the shader interface, then it's more natural to say that the driver
should link varyings by name dynamically, probably with the help of
common code, than saying that for TGSI).