Brian Paul wrote:
> 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.
Heh, I also made some changes on the vbo branch... We should sync up.
I have ended up with three modes of operation: Legacy, NV and ARB.
Legacy:
0..15 are the well known POS..TEX8 values
16..31 are the per-vertex Material attributes, plus some padding
NV (NV vertex program enabled):
0..15 are either POS..TEX8 or NV attribs 0..16, according to aliasing
rules
16..31 are padding.
ARB:
0..15 are the POS..TEX8 values
16.31 are the 16 generics.
This scheme obviously doesn't incorporate the support in the GLSL branch
for 32 generics, but it works well for the existing attributes, and
avoids several problems in the current code.
Have a look at vbo_exec_array.c if you want.
Keith
-------------------------------------------------------------------------
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
