Oliver McFadden wrote:
> Hi,
> 
> I believe I've found a few bugs caused by the unaliasing of generic vertex
> attributes (commit 095c6699f449ed4803f23e844cc0227743a9c3e1), specifically in
> the file src/mesa/shader/arbprogparse.c:
> 
>          case VERTEX_ATTRIB_GENERIC:
>             {
>                GLuint attrib;
>                if (!parse_generic_attrib_num(ctx, inst, Program, &attrib)) {
>                   *is_generic = 1;
>                   /* Add VERT_ATTRIB_GENERIC0 here because 
> ARB_vertex_program's
>                    * attributes do not alias the conventional vertex
>                    * attributes.
>                    */
>                   if (attrib > 0)
>                      *inputReg = attrib + VERT_ATTRIB_GENERIC0;
>                }
>             }
>             break;
> 
> Notice that VERT_ATTRIB_GENERIC0 is added to the attribute number, which is
> effectively *inputReg = attrib + 16;
> 
> This does make sense, since this commit is supposed to unalias the generic
> vertex attributes from the conventional vertex attributes and the commit does
> add 16 extra attributes. However, in the file src/mesa/main/config.h
> MAX_NV_VERTEX_PROGRAM_INPUTS (used for both NV and ARB) is still defined to 
> 16,
> when it should be 32 to allow for the extra attributes.

This is an area I've changed a bit on the glsl-compiler-1 branch.  The 
bottom line is there's 16 attributes (aliased) for the NV extension and 
32 attributes for the ARB extension (actually 31, since generic 
attribute 0 still aliases with the glVertex/position attribute).  The 
constants in config.h don't precisely convey that.


> I'm also a little confused on how to use generic vertex attributes now. I 
> guess
> it should just be a case of using attributes >= 16 in both the program's code,
> and the vertex program, correct?

Unfortunately, the ARB kind of screwed over the app developer when they 
made aliasing optional in the GL_ARB_vertex_program extension (I argued 
for it, BTW).  Depending on whose OpenGL you're using, you may or may 
not get aliasing.

The safe thing to do is assume that attributes do alias and avoid 
conflicts.  For example, if you need color, texcoord and a few generic 
attributes.  Be aware that generic attribs 3 and 8 will correspond to 
the color and texcoord attributes, so you should avoid using them as 
generics.



> Anyway, here is a small patch (more of a hack) that I did to fix the old
> behaviour, but this is not the correct solution. Unfortionally I don't really
> know the depths of Mesa3d well enough to know in detail what needs to be 
> fixed.
> 
> diff --git a/src/mesa/shader/arbprogparse.c b/src/mesa/shader/arbprogparse.c
> index de63c50..9f4a2dc 100644
> --- a/src/mesa/shader/arbprogparse.c
> +++ b/src/mesa/shader/arbprogparse.c
> @@ -1542,7 +1542,7 @@ parse_attrib_binding(GLcontext * ctx, GLubyte ** inst,
>                     * attributes.
>                     */
>                    if (attrib > 0)
> -                     *inputReg = attrib + VERT_ATTRIB_GENERIC0;
> +                     *inputReg = attrib;
>                 }
>              }
>              break;

That'll break some things.  If you've got a test program that exhibits a 
problem, please file a bug report.  I'll look into it then.

-Brian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to