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

[Luca Barbieri]

> I think the only complication is in the state tracker where we'll have to examine the fragment shader during raster state validation to determine > if/where we need to set sprite_coord_enable bits.

Couldn't we just set the one for the PNTC generic unconditionally if
point sprites are enabled, and the others depending on GL coord
replace enables?

Is there hardware that wouldn't like this very much for some reason?

> It seems to me that if bit 'k' is set in sprite_coord_enable then GENERIC[k]
> should get the auto-generated texcoord.  That's how it's interpreted in the
> draw module but not in the state tracker (we're just getting lucky there
> because texcoord[i] is usually generic[i]).
As far I can tell it's the opposite: the state tracker interprets it
as GENERIC[k] and draw uses vertex shader output slot k.

> BTW, I think it's helpful to think of sprite coord gen as something that's
> done for fragment shader inputs, not vertex shader outputs.
Yes, indeed.

> Does my definition of sprite_coord_enable above sound good?

OpenGL is fine with it. I'm not totally sure what the DirectX 9
semantics are, but it seems it only has a boolean for sprite coord
replacement, so hopefully that works too.

On the other hand, according to Keith Whitwell, GENERIC indices are
supposed to be arbitrary up to either 2^32, 256 or some "high" number,
so if that interpretation stands, it would be somewhat weird for the
first 32 GENERICs to have the special status of possibly being sprite
coordinates.
This is much more an argument in favor of somehow revisiting the idea
of the arbitrary indices, though.