Is it bad to lock a VB for long time?

Started by
3 comments, last by Vertex333 15 years, 6 months ago
If I have the option to lock a VB (vertexbuffer), create the vertex data directly into the VB and unlock it, or create the vertex data into memory, lock a VB, simply memcopy the vertex data and unlock the VB. What would be better? Do not consider additional memory consumption. Everything is singlethreaded. All I want to know is if the duration of the VB lock should be small or not. (In other words is it bad to lock the VB for long time if the CPU couldn't present/update the frame anyway) The whole time (creation and locking) should be about the same for both anyway. Long time means !not! seconds or so. Thx, Vertex
Advertisement
It's not so much the time that the VB is locked for that is important, but the time taken to build the vertex buffer in general. If it takes the same time using either of the methods you describe, you still can't draw the contents of the buffer until it is constructed so it doesn't matter. In a single threaded environment, it won't make any difference.

Multithreaded is a different kettle of fish.

Savings can be made however if you don't need to recreate the WHOLE buffer every time. In your other post for example, if only one thing has changed, it would probably be worth caching the data hasn't changed, so you only recreate what you need to.
Remember that the CPU may well be ahead of the GPU (upto 3 frames usually) so locking a VB that is involved in rendering an earlier frame may well force a sync between CPU<->GPU which is bad for performance...

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

Some drivers get confused when the lock and unlock doesn’t happen in the same frame. Therefore it is recommend after a long time lock doing a second lock/unlock pair.
Quote:Original post by jollyjeffers
Remember that the CPU may well be ahead of the GPU (upto 3 frames usually) so locking a VB that is involved in rendering an earlier frame may well force a sync between CPU<->GPU which is bad for performance...

hth
Jack
But this should be a problem for both, short or long lock operations, shouldn't it?
Quote:Original post by Demirug
Some drivers get confused when the lock and unlock doesn’t happen in the same frame. Therefore it is recommend after a long time lock doing a second lock/unlock pair.
Hi Demi! ;) (3DC)
Same frame on the CPU or GPU? Does that mean that I need to lock it more than once although I am outside Begin/EndScene (depending on the CPU/GPU question)?

Besides:In my case, frametime/update may be fixed to a minimum of 100ms anyway. Up to some thousands of Drawcalls/RS changes per frame.

Thx,
Vertex

This topic is closed to new replies.

Advertisement