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

[Marek Olšák]

On Thu, Aug 26, 2010 at 12:55 AM, Luca Barbieri <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.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100826/f926d7b4/attachment.html>