Keith Whitwell wrote:
> Just a heads up that we're doing a bit of work to try and improve the
> process of uploading buffer data, in particular vertex buffer data, and
> piggy-backing on that some potential rethinking about the way we expose
> things like "map buffer" in gallium.
>
> The trigger for this is the code in the VBO module, which seems typical
> of a lot of application usage of vbo's for dynamic data. Basically
> these apps want to do something like this:
>
> loop {
> map buffer
>
> append some hard-to-precalculate number of vertices to whatever
> else is already in the buffer
>
> unmap buffer
> emit_some_state()
> draw_primitives()
> if (buffer_full)
> get_new_buffer()
> }
>
>
> The problem is that the existing glMapBuffer() semantics don't really
> allow a buffer to be remapped after it has been referenced in a draw
> call -- the underlying driver would be expected to do things like
> copying the old contents to ensure that they could not be overwritten,
> etc. Or, in the case where the draw has been submitted to hardware, the
> driver would need to wait on a fence prior to mapping the buffer.
> Current dri/gallium drivers tend to only implement the second check,
> which is a bit naughty.
>
> In any case, the apps & vbo module don't really want to provoke all this
> extra work, so (assuming they still want to use vbo's) they end up
> effectively getting a new buffer after each draw_primitives() call, even
> though the old one may only hold a tiny number of vertices.
>
> GL has an extension which addresses this, GL_map_buffer_range, which
> provides asyncrhonous flags for mapping and additional functions for
> marking buffer regions as dirty and requiring update. It's interesting
> to think about what it really means to mark just a small region of a
> buffer dirty and what possibilities that opens up for the driver and
> backend implementation. It's probably worth a separate email...
>
> In the meantime, Jose & I have been experimenting with an asynchronous
> mapping change to try and improve the behaviour of the vbo module & cut
> down on the worst cases of excessive buffer usage. This is a simple
> DONT_WAIT flag which allows the buffer_map operation to fail if it would
> have blocked. This isn't exactly the same as the semantics from the
> extension, but is somewhat memory-manager friendlier -- it doesn't allow
> mapping a buffer which is currently being accessed by the GPU, for
> instance...
>
> Hopefully I've structured the change so as not to affect existing
> drivers, and allow people to turn on this behaviour fairly easily once
> it's baked. However, it's probably a bit early to start putting much
> work into it as this may change further -- in particular we're looking
> at what it would take to support the full map_range semantics, and
> possibly rethinking how gallium exports the buffer mapping
> functionality.
On a loosely related note...
With OpenGL 3.1 there's only going to be array-based drawing with
glDrawArrays/Elements(); no immediate mode and no dlists.
When we get to 3.1 I'm thinking we can omit the VBO module entirely and just do
the array/draw setup in the gallium state tracker. It should be a fairly thin
bit of code. Though, I don't know all the nooks and crannies of the VBO code
like you do.
What do you think?
-Brian
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
