On Thu, Aug 26, 2010 at 4:08 AM, Luca Barbieri <[email protected]>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
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
