[Mesa-dev] per-vertex array max_index

[Brian Paul]

On 04/15/2011 03:33 PM, Marek Olšák wrote:
> Hi Brian,
>
> The main reason for removal of pipe_vertex_buffer::max_index was its
> direct dependence on pipe_draw_info. The vertex buffer field was
> directly computed from the parameters of pipe_draw_info instead of being
> a completely independent state. So we ended up doing this in st/mesa:
>
> set_vertex_buffer
> draw_vbo
> set_vertex_buffer
> draw_vbo
> set_vertex_buffer
> draw_vbo
>
> And this was completely impossible due to lack of info from GL when
> setting vertex pointers:
>
> set_vertex_buffer
> draw_vbo
> draw_vbo
> draw_vbo
>
> Adding pipe_vertex_buffer::max_index back would be no different from
> putting vertex buffers in pipe_draw_info, because there is a direct
> dependency between them. In u_vbuf_mgr when draw_vbo is called, we try
> to guess the index bounds the same way we do it for GL (simply because
> there is no other way).
>
> 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.

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.


> 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