[Mesa-dev] Mesa (master): r300g: fix gl_PointCoord
brianp at vmware.com
Wed Aug 25 16:49:12 PDT 2010
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?
>> 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
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.
More information about the mesa-dev