> 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. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
