[Mesa-dev] per-vertex array max_index

[Christoph Bumiller]

On 16.04.2011 02:29, Brian Paul wrote:
> On 04/15/2011 03:33 PM, Marek Olšák wrote:
>> Let's decompose the whole problem of computing max_index into several
>> cases:
>>
>> 1) Is the vertex buffer a non-user buffer?
>> - If stride == 0, max_index = 1.
>> - Otherwise, max_index = (width0 - buffer_offset - src_offset) /
>> stride - 1.
>>
>> That should work for user vertex buffers too, but there is an
>> alternative way without having to use width0, it's what st/mesa is doing
>> (though it might be wrong for instanced arrays, I didn't check):
>>
>> 2) Is the vertex buffer a user buffer?
>> - If stride == 0, max_index = 1.
>> - If instance_divisor != 0, max_index = start_instance +
>> instance_count - 1.
>> - If !indexed, max_index = start + count - 1.
>> - Otherwise, st/mesa must go through the index buffer and obtain
>> max_index from there (which it does).
>>
>> There is no other way to compute max_index from the info we have from
>> GL.
>
> Right, I understand all that.
>
>
>> So that's all for the max_index issue.
>
> But according to Jose, draw_info::max_index has nothing to do with
> bounds checking; it basically describes the range of indexes specified
> by the user in glDrawElements().  The driver can use this as a hint to
> minimize fetching/moving/copying vertex data.
>
But you can't do bounds checking on user (non-VBO) vertex buffers
anyway, you have to rely on the user to not specify out-of-bounds indices.

For VBOs you still have the buffer size / stride as a bound against
which you can check draw info's max_index (from index buffer or array
start + count, either way that's per draw call) or max_instance.

If the state tracker sets max_index to ~0 (like d3d1x always does), it
obviously didn't care to compute the max index for you and you're left
with checking against the provided buffer size (which luckily the GPU
does for me, I agree bounds checking is quite useful).

Wouldn't vertex_buffer.max_index just be something like
MIN(draw_info.max_index, buffer_size / element_size) ?

> It seems there's a disconnect here between what you describe above and
> what Jose described for draw_info::max_index.
>
> Note that draw_info::max_index is passed all the way down into the
> gallium vertex translation module where it's applied to all vertex
> array indexing, including instanced arrays.  And that's causing the
> current failures.
>
Would it be a problem to just not apply it to per-instance buffers /
elements ?
>
>> On a slightly different note, we can't completely decouple the
>> set_vertex_buffer and draw_vbo calls due to some trickery in the vbo
>> module, so there is still a long way to go to make the two really
>> independent of each other, i.e. several glDrawElements calls shouldn't
>> cause calling set_vertex_buffer each time, but they sometimes do.
>
> It seems to me that at least in some cases, we could bypass the VBO
> module completely when drawing from VBOs and vertex arrays.  I haven't
> explored that in any detail though.
>
> Another idea I had was to take more advantage of Vertex Array Objects.
>  With VAOs, all the info about the arrays is packaged up into a nice
> data structure (gl_array_object) that the state tracker could augment
> with gallium vertex array info.  If we do a sequence of glDraw() calls
> with one VAO, we should be able to reuse the gallium vertex array info
> associated with the VAO and not recompute all that stuff.
>
> -Brian
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev