<div class="gmail_quote">On Thu, Aug 26, 2010 at 4:08 AM, Luca Barbieri <span dir="ltr"><<a href="mailto:luca@luca-barbieri.com" target="_blank">luca@luca-barbieri.com</a>></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 r300->r500, if there are both a vertex shader output and sprite coords at<br>
> the same varying index, the output takes precedence, meaning that it behaves<br>
> as if sprite coords were disabled. This is OK because Gallium doesn't<br>
> specify which one to write to FS if there are both at the same slot. If you<br>
> think that sprite coords should take precedence instead, I could remap them<br>
> to another slot, but I need to think about it little more to see how to<br>
> implement the remapping. It's not as easy because vertex shader outputs<br>
> cannot be disabled once they are written to in the vertex shader.<br>
</div>As far as I can tell, GL requires that sprite coordinates take<br>
precedence over ARB_vertex_program outputs.<br>
Why do things work right now, if Gallium and r300-r500 behave as you explained?<br></blockquote><div><br>gl_PointCoord is set correctly if the vertex shader doesn't write to GENERIC0. I know it's not nice.<br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> Whatever will be the final solution, please consider that ideally we should<br>
> only have one way to setup sprite coords in gallium. If we had a special<br>
> shader semantic for PNTC, we should fix the texenv (fixed-function) program<br>
> to use the new semantic too and abandon sprite_coord_enable. Having 2 ways<br>
> to program point sprites, one for GLSL and another for everything else, is<br>
> no good.<br>
<br>
</div>What about ARB_vp/ARB_fp?<br>
You would need to recompile the fragment shader when you change the<br>
sprite coord replacement settings in your proposal, if I understand it<br>
correctly. This might actually be good, but is a significant change.<br></blockquote><div><br>I wasn't proposing anything, I was making an example and trying to point out that there should only be one way to setup sprite coords, unlike now.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Also, doesn't sprite coord replacement also affect gl_TexCoord in GLSL?<br>
</blockquote></div><br>I suspect it does.<br><br>Marek<br>