<div class="gmail_quote">On Thu, Aug 26, 2010 at 12:55 AM, Luca Barbieri <span dir="ltr">&lt;<a href="mailto:luca@luca-barbieri.com" target="_blank">luca@luca-barbieri.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>&gt; I think the only complication is in the state tracker where we&#39;ll have to examine the fragment shader during raster state validation to determine &gt; if/where we need to set sprite_coord_enable bits.<br>

<br>
</div>Couldn&#39;t we just set the one for the PNTC generic unconditionally if<br>
point sprites are enabled, and the others depending on GL coord<br>
replace enables?<br>
<br>
Is there hardware that wouldn&#39;t like this very much for some reason?<br></blockquote><div><br>On r300-&gt;r500, if there are both a vertex shader output and sprite coords at the same varying index, the output takes precedence, meaning that it behaves as if sprite coords were disabled. This is OK because Gallium doesn&#39;t specify which one to write to FS if there are both at the same slot. If you think that sprite coords should take precedence instead, I could remap them to another slot, but I need to think about it little more to see how to implement the remapping. It&#39;s not as easy because vertex shader outputs cannot be disabled once they are written to in the vertex shader.<br>


<br>Whatever will be the final solution, please consider that ideally we should only have one way to setup sprite coords in gallium. If we had a special shader semantic for PNTC, we should fix the texenv (fixed-function) program to use the new semantic too and abandon sprite_coord_enable. Having 2 ways to program point sprites, one for GLSL and another for everything else, is no good.<br>


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