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

[Brian Paul]

On 08/25/2010 04:55 PM, Luca Barbieri wrote:
>> 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?

I don't know.  I'd have to start coding it up but I don't have any 
time for that.


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

Don't know.


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

Hmmm, I'll have to study the code some more when I get time.


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

I think we'll be OK as long as OpenGL's limited to 32 texcoord units 
(and Mesa's limited to 8).


> This is much more an argument in favor of somehow revisiting the idea
> of the arbitrary indices, though.


-Brian