On Tue, 2009-03-03 at 10:19 -0800, Brian Paul wrote:
> 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,
Yes, this makes sense. The vbo/ code is really just about supporting
the wide variety of rendering modes present in legacy gl.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
