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.
Keith
------------------------------------------------------------------------------
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
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
