Locking vertex and index buffer while rendering
Let me see if I got this one right.
I have a vague memory of reading that if I have a vertexbuffer and lock it with the discard flag, then I can get a buffer to write into while the gfx card is still rendering the previous buffer that I locked. Is this correct?
Will I need to do this in two threads then? As far as I know, the drawPrimitives call is blocking so it does not return before rendering is done.
What I would like to do is to render with a vertex buffer and an index bufferwhileI am showeling vertices into a vertex buffer and an index buffer that I locked. That way I can double my speed, assuming that the showleing and rendering takes the same amount of time.
 Thomas Greenleaf wrote: |
Will I need to do this in two threads then? As far as I know, the drawPrimitives call is blocking so it does not return before rendering is done.
|
|
That's mistaken. DrawPrimitives and friends just put a queued operation in a command buffer that'll get pushed to the device at some point. However, if you modify some data (texture, vertex buffer, etc) after the draw command, the driver may decide to stall until that piece of data has actually been rendered.
Locking with DISCARD, when you're using DYNAMIC pool data, will allow you to avoid this stall; the driver will keep the old data around and will give you a new (different) chunk of memory to write into when you do the lock.
Not even Present() is necessarily blocking, unless you already have enough buffered that the driver needs to wait for another back buffer to become available to render into.
Thanks for your answer. It makes sence that way.
Just to make absolutely sure that I understand this right...
I can perfectly well do things in this order, and not get stalled by a blocking call?
lock a vertex buffer
copy data to the buffer
call render, which returns immediately
call present, which returns immediately
lock and copy again
So if my screen frequency is 60Hz and I do have vsync turned on, I can full well run at 60FPS even if the lock and copy takes just about 1/60s and the render also takes almost 1/60s.
The folowing sequence will result in (c,d) running (on the gpu) overlpped with (e,f), correct?
a:lock a vertex buffer
b:copy data to the buffer
c:render
d:present
e:lock a vertex buffer
f:copy data to the buffer
If I have only one backbuffer, then a second call to render will block untill the first rendercall has been presented (by calling present)?
By using more backbuffers, I can render a few frames ahead, but the speed would be the same. Only difference would be that I can even out a slow frame with faster frames. ?
