-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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()
> }
This is a usage model that a lot of apps really want to use. During the
process of developing the representatives from Blizzard and Transgaming
were very strong proponents.
> 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...
The subrange flush is, IMO, not well specified. The spec allows two
different behaviors that will give potentially different results to apps.
1. Flush the subrange immediately when glFlushMappedBufferRange is
called. I believe this is what Apple implements for
glFlushMappedBufferRangeAPPLE (see
http://www.opengl.org/registry/specs/APPLE/flush_buffer_range.txt)
2. Collect marked subranges and flush on glUnmap. This seems like it
would be the more sensible implementation for the existing memory
managers in Mesa.
Peering into my crystal ball, I suspect the restriction preventing
rendering while a buffer is mapped may eventually be lifted. If / when
that happens, I can see apps moving to loops like:
map()
while () {
generate_data();
flush();
draw();
}
unmap();
> 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...
Is this an extra MAP_*_BIT for glMapBufferRange or does it only exist in
the internal interface?
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm39Q4ACgkQX1gOwKyEAw/k5gCdHO0Isihi87D0YTVfhRLqZt2J
1q8AoJ7i5rN37N6w6eHFS9vXLKa4xZ9k
=s6fh
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
