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

[Roland Scheidegger]

On 26.08.2010 04:08, Luca Barbieri wrote:
>> 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?
Hmm this is actually a good question. Generally tex env state does not
apply when glsl fs is active, but point sprite coord replacement isn't
actually true texenv state. If it wouldn't apply, it would be impossible
to use point sprites in glsl 1.10 (since gl_Pointcoord was added in 1.20
only), so I think that yes this should indeed apply (some quick googling
shows at least some fglrx versions didn't agree neither - guess we're
not the first to hit problems around that...).

Roland