[Mesa-dev] Mesa (master): r300g: fix gl_PointCoord
sroland at vmware.com
Wed Aug 25 19:04:19 PDT 2010
On 26.08.2010 03:17, Marek Olšák wrote:
> On Thu, Aug 26, 2010 at 12:55 AM, Luca Barbieri <luca at luca-barbieri.com
> <mailto:luca at luca-barbieri.com>> 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?
> Is there hardware that wouldn't like this very much for some reason?
> 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.
> 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.
This looks like a clean solution, note though this seems to imply two
variants of the texenv prog needs to be potentially maintained and
consequently switched depending on the current primitive, one for points
(when point sprite is enabled) and another one for all non-point primitives.
More information about the mesa-dev