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

[Luca Barbieri]

The issue is in the Mesa state tracker.

In particular, it currently maps FRAG_ATTRIB_PNTC (used by GLSL
gl_PointCoord) to GENERIC[0] unconditionally.

Hence, the "| 1" in the nvfx driver puts the sprite coordinate in
GENERIC[0] if point_quad_rasterization is enabled.

This mapping by mesa/st is obviously incorrect since it overwrites
texcoord0 while it shouldn't (unless GL coord replace is also enabled
for it).
The mesa/st code actually includes several comments that state that
this is an hack.

mesa/st should be fixed to put FRAG_ATTRIB_PNTC in a GENERIC slot not
used by anything else, or in a different semantic.

Currently, it "mostly works" because non-GLSL shaders will not use
FRAG_ATTRIB_PNTC, and GLSL shaders will typically use user-defined
varyings and not gl_TexCoord[0].

Also, "sprite_coord_enable" is interpreted by some drivers (e.g.
r300g) as being indexed by GENERIC index (thus preventing GENERICs >=
32 from getting sprite coordinates), and by some others (e.g. draw) as
being indexed by the position of the output in the set of all outputs
written by the vertex shader.

Again, by chance, these interpretation are often equivalent in
practice, but this broken too.

This is part of the broader issues with shader linkage in Gallium,
which is not documented and is implemented in different, incompatible
and partially broken ways by essentially all drivers.
A previous attempt at fixing this by me failed to reach any consensus
on how to fix this, mostly because every API and every GPU does it
differently, and it's not clear how to unify all of them (see
http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg13102.html
for a summary).