Archived

This topic is now archived and is closed to further replies.

Raloth

locking a static vertex buffer

Recommended Posts

Raloth    379
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?

Share this post


Link to post
Share on other sites
Raptor85    180
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."

Share this post


Link to post
Share on other sites
Raloth    379
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.

Share this post


Link to post
Share on other sites
glassJAw    128
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]

Share this post


Link to post
Share on other sites
> 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.

Share this post


Link to post
Share on other sites
Raloth    379
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...

Share this post


Link to post
Share on other sites
GekkoCube    116
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?

Share this post


Link to post
Share on other sites
Hawkeye3    122
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]

Share this post


Link to post
Share on other sites
Raloth    379
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.

Share this post


Link to post
Share on other sites
Matt Halpin    139
quote:
Original post by Raloth
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.


It should be fine to do this. I''m doing it plenty in the current game I''m working on, and I don''t have a choice. In the game, you can place and remove items whenever you want (the user, that is). But the items can have such small vertex counts that the overhead of drawprim calls would be too much when rendering 1000s or 10000s of them (you wouldn''t even be able to render 10000 at a decent frame rate). Hence I batch them up into big vbuffers. Now, if I were to use dynamic buffers I''d be sucking up AGP bandwidth every frame for something that doesn''t change every frame, hence limiting the amount of true dynamic data I can have. So the only alternative is to batch into static buffers, and lock when an item is added or deleted (obviously only lock and fill as little as possible).

This should be ok, and if it isn''t on specific cards/drivers then contact the relevant IHV. That''s what I intend to do if I find a problem.

HTH

Matt Halpin

Share this post


Link to post
Share on other sites