Is there any problem with locking a vertex buffer for an extended period of time (say, less than a frame)? I need to throw a dynamic vertex buffer into my rendering class. I have three options for adding vertices: 1) Add vertices to a vector, then just before rendering, copy them to the vertex buffer. (the simple choice) 2) Lock the vertex buffer each time I need to add a vertex. (even if I just lock small portions of the VB, this seems like the obvious bad choice). 3) Lock the vertex buffer at the start of adding vertices, unlock it just before rendering. It seems like option (3) would be the fastest unless there are some sort of caching or vid. card problems. Suggestions?

I also think option 3 is preferable since you lock the vb only once (per frame), dynamicaly fill it with vertices and unlcok it once before rendering.
Copying a vector to the vertex buffer (PER FRAME !), especially a high number of vertices will be slow and reduce your frame rate, and it still requires locking and unlocking the vb. (think, for copying data to a vb you need access to it, which is done by locking it)
Option number 2 is out of the question if you ask me ;)

I'd actually hazard a guess that #1 is the better option.

Holding a lock for an extended period of time (okay, a frame is 5-20ms, but relatively its a long time) means that the GPU cant use that resource (or anything indirectly related) for the duration that the lock is held. Best case is it just stalls that particular resource, worst case is that it somehow creates a dependency that stalls other parts.

Given that GPU's tend to run ahead and render ahead of what is currently being displayed you could possibly lock the buffer for a future frame and consequently stall it from completing a previous frame that is already deep in the pipeline.

Bottom line is that the two strategies should be fairly trivial to implement in code, so go do some stress-testing and benchmarking [grin]

I would imagine the trade-off is going to be whether the extended lock stalls performance versus whether throwing up a big chunk of data in a single copy operation is slow due to bandwidth overheads...

hth
Jack

Well, option (3) isn't going to work now that I started implementing it. The whole reason I wanted to do it this way is that it is indirect. Objects simply add themselves to the render class. The render class does not draw them until they have been sorted and optimized. Thus, for option (3), once the dynamic VB is full, it must be rendered before more vertices can be added.

So I decided on option #1, and to keep down on bus speed, I'm going to throw in a dynamic index buffer as well to limit the number of vertices sent.

I hope the memcpy isn't too slow from the vector to the vbuffer and ibuffer. I don't think it will be a bottle neck. And with this method I can throw the vertex generation in a seperate thread.

Thanks for the suggestions.

In my experience copying an array into a vertex buffer is significantly faster than writing small chunks of memory to it. (Even when the lock is short.)

My guess for the reason is that locking can give you an AGP memory chunk to write to, and that uses writethrough instead of writeback for normal memory.