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

[Brian Paul]

On 08/25/2010 09:09 AM, Luca Barbieri wrote:
> 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.

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?


> 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.

I'm having trouble understanding what you mean there.


> 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).


-Brian