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

Marek Olšák maraeo at gmail.com
Wed Aug 25 19:19:05 PDT 2010


On Thu, Aug 26, 2010 at 4:08 AM, Luca Barbieri <luca at luca-barbieri.com>wrote:

> > 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.
> As far as I can tell, GL requires that sprite coordinates take
> precedence over ARB_vertex_program outputs.
> Why do things work right now, if Gallium and r300-r500 behave as you
> explained?
>

gl_PointCoord is set correctly if the vertex shader doesn't write to
GENERIC0. I know it's not nice.


> > 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.
>
> What about ARB_vp/ARB_fp?
> You would need to recompile the fragment shader when you change the
> sprite coord replacement settings in your proposal, if I understand it
> correctly. This might actually be good, but is a significant change.
>

I wasn't proposing anything, I was making an example and trying to point out
that there should only be one way to setup sprite coords, unlike now.

Also, doesn't sprite coord replacement also affect gl_TexCoord in GLSL?
>

I suspect it does.

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


More information about the mesa-dev mailing list