On Wed, Aug 25, 2010 at 5:39 PM, Brian Paul <[email protected]> wrote:
> 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? Just out of curiosity, why should there be a new semantic label? Isn't the sprite_coord_enable bitfield good enough for marking an existing fragment shader GENERICn slot that expects sprite coords? Marek
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
