[Mesa-dev] Mesa (master): r300g: fix gl_PointCoord

[Luca Barbieri]

> On r300->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'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's not as easy because vertex shader outputs
> cannot be disabled once they are written to in the vertex shader.
As far as I can tell, GL requires that sprite coordinates take
precedence over ARB_vertex_program outputs.
Why do things work right now, if Gallium and r300-r500 behave as you explained?

> 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.

What about ARB_vp/ARB_fp?
You would need to recompile the fragment shader when you change the
sprite coord replacement settings in your proposal, if I understand it
correctly. This might actually be good, but is a significant change.
Also, doesn't sprite coord replacement also affect gl_TexCoord in GLSL?