[Mesa-dev] per-vertex array max_index

[Brian Paul]

On 04/15/2011 01:41 PM, José Fonseca wrote:
> On 04/15/2011 07:20 PM, Christoph Bumiller wrote:
>> On 15.04.2011 18:04, Brian Paul wrote:
>>
>>> Hi Marek,
>>>
>>> Back on Jan 10 you removed the per-vertex array max_index field
>>> (commit cdca3c58aa2d9549f5188910e2a77b438516714f).  I believe this was
>>> a mistake.
>>>
>>> I noticed today that the piglit draw-instanced-divisor test is
>>> failing.  A bisection points to Jose's commit
>>> 17bbc1f0425b3768e26473eccea5f2570dcb26d3.  But that's a red herring.
>>> If I disable the SSE code paths, the regression goes back to the Jan
>>> 10 change.
>>>
>>> With the GL_ARB_instanced_arrays extension vertex array indexing
>>> changes quite a bit.  Specifically, some arrays (those with divisors
>>> != 0) are now indexed by instance ID, not the primitive's vertex
>>> index.  The draw_info::max_index field doesn't let us take this into
>>> account.  I believe that we really need a per-array max_index value.
>>>
>>> As an example, suppose we're drawing a star field with 1 million
>>> instanced stars, each star drawn as a 4-vertex quad.  We might use a
>>> vertex array indexed by the instance ID to color the stars.
>>>
>>> The draw call would look like:
>>>
>>> glDrawArraysInstanced(GL_QUADS, 0, 4, 1000*1000);
>>>
>>> In this case we'd have two vertex arrays.  The first array is the quad
>>> vertex positions with four elements.  The second array is the star
>>> colors with 1 million elements.  As it is now, we're setting
>>> draw_info::max_index = 4 and we errantly clamp the index into the
>>> second array to 4 instead of 1 million.
>>>
>>> As a temporary work around we can disable clamping of array indexes
>>> for instance arrays.  But I think we need to revert the Jan 10 commit
>>> and then rework some of Jose's related changes.
>>>
>>> -Brian
>>>
>>>
>> You know which vertex elements are per-instance, you know the divisor,
>> and you know the max instance index - that should be all the information
>> you need.
>>
>> You just have to clamp it to startInstance + instanceCount for them instead.
>>
>>
>
> draw_info::max_index is an optimization hint. In theory it could be always 0xfffffff and the pipe driver should still cope with it. Provided it is an upper bound of the true max index in the index buffer it should cause no visible difference.
>
>
> My u_draw.c code already ignores instanced elements when computing
> max_index.
>
> And I believe the translate module doesn't clamp to max_index when
> fetching instanced elements, but I'll have to double check.
>
> I didn't look too closely at current st_draw.c code though yet. But it
> appears the bug is in st_draw.c, as there is no need to artificially
> limit the max_index passed by the app.

I thought we were using max_index to prevent out-of-bounds buffer 
reads.  Are we not doing that anywhere?

-Brian