[Mesa-dev] explaining update_arrays

Brian Paul brianp at vmware.com
Wed Jun 22 13:52:23 PDT 2011


On 06/22/2011 02:36 PM, Dave Airlie wrote:
>>>
>>>> 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.
>>
>> In GLSL, only attribute 0 / glVertexArray alias.  The other non-generic
>> arrays can only be accessed via the named built-in variables (e.g.,
>> gl_Color).
>
> Ah that makes sense, thanks guys,
>
>>
>>> Do you suspect a bug here?
>
> No but this codepath is a real dog on profiles, and I'm guessing 90%
> of it useless in 90% of profiles,
> like in an app that doesn't use VBOs it pretty much could end up as
> min = 2*1000*1000*1000; but
> to figure that out it has a lot overhead. I'm guessing we should
> probably push working out the array max
> closer to the edges and not in this path if we can.

Agreed.  I'd like to get rid of that code.  If we can push the 
responsbility of not fetching vertex data from out of bounds down into 
the drivers, that would simplify core Mesa.

-Brian


More information about the mesa-dev mailing list