<div class="gmail_quote">On Wed, Aug 25, 2010 at 5:39 PM, Brian Paul <span dir="ltr">&lt;<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">



<div>On 08/25/2010 09:09 AM, Luca Barbieri wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The issue is in the Mesa state tracker.<br>
<br>
In particular, it currently maps FRAG_ATTRIB_PNTC (used by GLSL<br>
gl_PointCoord) to GENERIC[0] unconditionally.<br>
<br>
Hence, the &quot;| 1&quot; in the nvfx driver puts the sprite coordinate in<br>
GENERIC[0] if point_quad_rasterization is enabled.<br>
<br>
This mapping by mesa/st is obviously incorrect since it overwrites<br>
texcoord0 while it shouldn&#39;t (unless GL coord replace is also enabled<br>
for it).<br>
The mesa/st code actually includes several comments that state that<br>
this is an hack.<br>
<br>
mesa/st should be fixed to put FRAG_ATTRIB_PNTC in a GENERIC slot not<br>
used by anything else, or in a different semantic.<br>
</blockquote>
<br></div>
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?</blockquote><div><br>Just out of curiosity, why should there be a new semantic label? Isn&#39;t the sprite_coord_enable bitfield good enough for marking an existing fragment shader GENERICn slot that expects sprite coords?<br>



<br>Marek<br></div></div>