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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
