Proper use of Dynamic Vertex Buffers for rapid update

Question

I am creating a C#/SharpDx/DirectX10 application to plot line charts in a fast way.

I have a prototype which uses Dynamic Vertex Buffers and fills a fixed-size buffer, say 1M vertices, with new data per frame.

I'm finding sometimes the vertex buffer is filled with new data while the GPU is still drawing the last batch (especially on slower GPUs). Here is my code to create, map, fill and flush a vertex buffer. I wonder if I'm using it in the right way?

// Declare the re-usable buffer (once)
SharpDX.Direct3D10.Buffer d3d10Buffer = new SharpDX.Direct3D10.Buffer(_d3d10Device,          
        new BufferDescription(size,
        ResourceUsage.Dynamic,
        BindFlags.VertexBuffer,
        CpuAccessFlags.Write,
        ResourceOptionFlags.None));

// ... 

// Per-frame, map the buffer, write vertices and draw + Flush()
DataStream vertexBufferStream = d3d10Buffer.Map(MapMode.WriteDiscard,   
        SharpDX.Direct3D10.MapFlags.None);
vertexBufferStream.Write((float)someValue);
vertexBufferStream.Write((float)anotherValue); 
// lots of writing ... 

// Then immediately draw
d3d10Buffer.Unmap();
vertexBufferStream.Dispose();
_d3d10Device.InputAssembler.SetVertexBuffers(0, 
       new VertexBufferBinding(_d3d10Buffer, 16, 0));

_d3d10Device.Draw(); // Assumes shaders and topology have been applied
_d3d10Device.Flush();

So I'm wondering, am I doing this the right way? The MSDN Documentation tells me not to call Flush, but I don't want to overwrite my (shared) dynamic vertex buffer when the next frame begins.

I also saw on the SharpDX website that MapFlags and MapMode have enumerations to prevent overwrite, would MapMode.WriteNoOverwrite and MapFlags.DoNotWait help in this scenario?

Answer 1

You're mapping with write-discard, so this isn't a problem at all (and the Flush is definitely not needed). If the buffer is currently in use for drawing the driver will just hand you a new block of memory when you map, and release the old memory when it's drawing has finished. Really clever drivers will actually keep the old block lying around and reuse it as a subsequent "new block" some frames later, so that instead of allocating/releasing memory each frame it's just continually cycling through the same few blocks - a classic multi-buffering approach but all handled for you automatically by the driver: neat!