[Mesa-dev] explaining update_arrays

[Brian Paul]

On 06/22/2011 08:20 AM, Roland Scheidegger wrote:
> Am 22.06.2011 16:11, schrieb Brian Paul:
>> On 06/22/2011 04:18 AM, Dave Airlie wrote:
>>> I don't suppose anyone could contribute a comment on why somethings
>>> check ctx->VertexProgram._Current,
>>> and others check ctx->VertexProgram._Enabled
>>
>> The former may point to a GLSL shader/program, a
>> GL_NV/ARB_vertex_program program or a shader derived from fixed-function
>> state.
>>
>> The later will only be true when a GL_NV/ARB_vertex_program program is
>> enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's
>> program compiled successfully).
>>
>> I haven't looked at all the places where _Enabled or _Current is used,
>> but there is a difference in what they mean.
>>
>>
>>> By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
>>> _Current
>>> and the others all check _Enabled, to me it would make some sense at
>>> least if 0
>>> was consistent with the others, but maybe someone knows what is correct.
>>
>> The confusion probably goes all the way back to the ARB's unfortunate
>> inability to reconcile NV's vs. ATI's different handling of generic
>> vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
>> made it optional (a mess).  Plus, I think there was some minor
>> difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
>> generic vertex arrays.
>
> Wasn't the difference just that ARB_vertex_shader made it non-aliasing
> instead of undefined aliasing, or was there more to it...

That's true, but then generic array[0] seems special.  It's not truly 
generic because it seems to override the legacy GL_VERTEX_ARRAY 
pointer.  But the spec seems to only indicate this in the 
ArrayElement() pseudo code.  The spec does explicitly say that 
glVertexAttrib(0,foo) is equivalent to glVertex(foo).

-Brian