[Mesa-dev] explaining update_arrays
brianp at vmware.com
Wed Jun 22 07:35:59 PDT 2011
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
>> 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
>>> 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 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).
More information about the mesa-dev