locking a static vertex buffer
Author
How bad is this, really ? I definately know not to do it every frame, but I was curious how much it actually hurts. I wrote a simple test app taking out the dynamic flag only cost me 30 fps. That isn''t much when it''s the difference between 240 and 210. This doesn''t really make sense to me since people seem to dread it a lot more than that. Could it be because my test didn''t push my video card past more than 5% of its capability? Locking a static buffer ''stalls'' the card but if it''s not doing anything then there''s nothing to stall.
The only reason I ask is because I am trying to implement a seamless world. Currently I am using a static vertex buffer for each small chunk and then I lock it and fill it with new data when it comes time to swap out map sections. Once the card gets working, will locking a couple static buffers (about six) once in a frame and then not again for a long time cause a noticeable frame jump? If so, would I be better off copying vertex data to a dynamic buffer every single frame instead?
locking vertex buffers while running is a very bad idea. it causes a slowdown because it has to re-send all the data to harware, effectively stopping all operations for the lock to happen.
quote from ms
"Locking a static vertex buffer while the buffer is in use by the graphics processor can have a significant performance penalty. The lock call must wait until the graphics processor is finished reading vertex or index data from the buffer before it can return to the calling application, a significant delay. Locking and then rendering from a static buffer several times per frame will also prevent the graphics processor from buffering rendering commands, since it will need to finish commands before returning the lock pointer. Without buffered commands, the graphics processor will remain idle until after the application is finished filling the vertex buffer or index buffer and issues a rendering command."
quote from ms
"Locking a static vertex buffer while the buffer is in use by the graphics processor can have a significant performance penalty. The lock call must wait until the graphics processor is finished reading vertex or index data from the buffer before it can return to the calling application, a significant delay. Locking and then rendering from a static buffer several times per frame will also prevent the graphics processor from buffering rendering commands, since it will need to finish commands before returning the lock pointer. Without buffered commands, the graphics processor will remain idle until after the application is finished filling the vertex buffer or index buffer and issues a rendering command."
Author
Yes yes I know that. What I''m asking is this: if I do it once, just one frame, to load the new data, is it going to be painfully noticeable? This would only happen when it needs to cache maps in and out.
quote:Original post by Raloth
Yes yes I know that. What I'm asking is this: if I do it once, just one frame, to load the new data, is it going to be painfully noticeable? This would only happen when it needs to cache maps in and out.
As long as it's not a massive VB, locking it once per frame should be fine. You might want to use a dynamic VB for that though: static VBs are good when you're switching between a bunch of VBs often. You don't seem to be doing that.
[edited by - glassJAw on August 9, 2003 1:46:49 AM]
> I was curious how much it actually hurts
This can vary with hardware and driver but it''s a pretty safe assumption that, at a minimum, the CPU is going to stall until the range of vertices in question is clear if they''ve previously been queued for rendering. The CPU may have to wait until the entire vertex buffer is clear. And you may encounter a driver that patronizingly thinks, since you''re locking this thing every so often, that what you really wanted in the first place was a dynamic VB and so it does you the "favor" of making it a dynamic VB (moving it into AGP memory).
As with so many things in PC 3D programming, there is no pat answer. Alas, the "semi-dynamic" usage you describe is not directly supported by the API.
This can vary with hardware and driver but it''s a pretty safe assumption that, at a minimum, the CPU is going to stall until the range of vertices in question is clear if they''ve previously been queued for rendering. The CPU may have to wait until the entire vertex buffer is clear. And you may encounter a driver that patronizingly thinks, since you''re locking this thing every so often, that what you really wanted in the first place was a dynamic VB and so it does you the "favor" of making it a dynamic VB (moving it into AGP memory).
As with so many things in PC 3D programming, there is no pat answer. Alas, the "semi-dynamic" usage you describe is not directly supported by the API.
Author
What if I make the vertex buffer managed? The MSDN says this will make (or should make) the driver keep a copy of the buffer in system memory. When I lock it will only have to lock the one in system and then send it to the card, instead of getting the buffer from the card and then back. It should be faster but it will still stall...
Interesting post since I am currently locking, filling, and the unlocking my static VB at every frame cycle - definitely a big hit (although my VB is only 600 in length).
Can somebody clear up the use of dynamic VB''s as opposed to static?
If you mean dynamic as in a dynamically allocated VB, I am having problems with that. every time i create a VB dynamically (ie. Direct3dvertexbuffer *pVB) even though the sixe is sufficiently large enough, nothing is drawn.
Also, when using a dynamic VB, how is the locking, filling, unlocking process different from that of a static VB?
Can somebody clear up the use of dynamic VB''s as opposed to static?
If you mean dynamic as in a dynamically allocated VB, I am having problems with that. every time i create a VB dynamically (ie. Direct3dvertexbuffer *pVB) even though the sixe is sufficiently large enough, nothing is drawn.
Also, when using a dynamic VB, how is the locking, filling, unlocking process different from that of a static VB?
Eh? A friend of mine has been pushing my particle system to the limit lately, which uses a dynamic vertex buffer to store the particle info. Currently he's able to run around 200 fps with 5000 particles( 20,000 vertices ) and I fill that buffer every frame. He does have a brand new alienware rig, but I can run it halfway decently too. This is also with all of the particle calculations (which aren't really optimized).
I get 50 fps using a 20,000 vert buffer on a gf3 ti200 and 1200mhz athlon, and most of the time goes towards re-initing the particles. It takes 0.006-0.007 seconds to init, the code that locks/ copies over to the vertex buffer takes 0.003 seconds.
[edited by - Hawkeye3 on August 9, 2003 12:31:54 PM]
I get 50 fps using a 20,000 vert buffer on a gf3 ti200 and 1200mhz athlon, and most of the time goes towards re-initing the particles. It takes 0.006-0.007 seconds to init, the code that locks/ copies over to the vertex buffer takes 0.003 seconds.
[edited by - Hawkeye3 on August 9, 2003 12:31:54 PM]
Author
quote:Original post by Dreddnafious Maelstrom
why wouldnt you simply use a dynamic VB? i dont get it.
Because most of the time I will not be locking the buffer. Rendering from a static buffer is faster than from a dynamic one.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
