Shawn Hargreaves Blog
ajmiles got it in one.
This harmless looking code:
graphicsDevice.VertexBuffer = vertexBuffer;
will cause a pipeline stall if the CPU reaches the SetData call for frame #2 before the GPU finishes processing the DrawPrimitives call from frame #1.
This occurs because resources such as vertex buffers and textures are passed by reference, not by value. You can think of each resource as a separate piece of paper filled with data:
This is efficient, because Charles does not have to bother touching the actual vertex data while processing the draw instruction.
But what if the game later calls SetData on this same vertex buffer?
If the GPU is still using the resource, the second SetData call must stall until it has finished.
There are several ways to avoid such a stall:
"Good for dynamic texture scenarios such as video playback."
I've a question. When you use he SetData method in the VertexBuffer class, the vertex buffer is locked, the data is sent to the video card and then it is unlocked, right ??
When you lock the vertex buffer you get an address to the buffer. Is this address a virtual address that allow you to direct access the video memory? Or the data is only updated when you call unlock ?
bpevangelista: in the native DirectX API, it depends: this can work either way depending on the driver and what usage flags you specify.
In the XNA Framework, there is no such thing as lock and unlock, just SetData.