Vertex Data Manager only efficiently handles static buffers that contain data in one set of vertex attributes

[GoogleCodeExporter]

If one static vertex buffer contains data for multiple objects, and those 
objects use different sets of vertex attributes, then the first draw call will 
translate all the data as the one set of vertex attributes, and the second and 
all subsequent calls will discover that their vertex attributes are missing and 
will convert the buffer to streaming.

The buffer will also periodically be converted back to static after a certain 
amount of data has been read from it, and almost instantly converted back to 
streaming. This ping ponging both wastes time converting creating and filling 
static vertex buffers unnecessarily, and doesn't take advantage of the fact 
that the data in the buffer is static and doesn't always need to be 
retranslated.

It would probably make sense to instead break the vertex buffer into multiple 
smaller vertex buffers, each vertex buffer corresponding implicitly to a draw 
call. Or we could create it as dynamic, and load the newly translated data for 
each draw call using NOOVERWRITE.

Original issue reported on code.google.com by jbauman@chromium.org on 18 Aug 2011 at 3:39

[GoogleCodeExporter]

Actually, it might be nice to create something to handle dynamic buffers - 
updated pretty often, but each piece of data in the buffer is used many times. 
This might be possible with a pool of dynamic vertex buffers that would be 
discarded upon buffersubdata only when necessary, but each is written into with 
what seem to be logically-contiguous pieces of data - say only things that were 
accessed in the same draw. They couldn't possibly cause the need for more 
translations than streaming buffers, at least, and if the data was grouped (and 
discarded) logically they could use a lot less. Of course, handling the 
transition between static, dynamic, and streaming might be difficult.

Original comment by jbauman@chromium.org on 18 Aug 2011 at 6:15