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-...@lists.sourceforge.net/msg13102.html for a summary). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
