2 replies to this topic

[Xcrypt]

As the title says. I'm wondering why the need for a dynamic vertexbuffer with DirectX if we can just recreate the buffer.
(regarding performance)

The reason I am asking this is because a lot of times, the vertexbuffer needs to be recreated anyway because additional vertices are introduced and the size of the original vbuffer is too small to hold all of the vertices. But why would we still a dynamic vbuffer then, it just seems like extra overhead.

[Reedbeta]

Allocating large amounts of video memory (e.g. creating a vertex buffer) in the middle of your frame is generally a bad idea. It's going to involve some overhead and it's even possible for it to introduce a CPU/GPU sync point, meaning the CPU will stall waiting for the GPU to finish all previous rendering, so that the CPU can shuffle some memory around and then kick off the rendering again.

Typically with a dynamic vertex buffer you would choose some arbitrary limit on how many vertices it can hold, and just allocate the buffer to be that size from the beginning. If the program runs out of space, then oh well, some particles (or whatever) will be missing. You can have your program write a log message or something to indicate that it ran out of space, so you can decide whether you should increase the static size of the buffer or not (trade off memory consumption vs ability to draw more particles or whatever).

[Xcrypt]

Sorry but I'm a dummy regarding GPU.
Does your previous post claim that the GPU renders async while the CPU(s) is(are) doing work? Even when you have no MT going on?
Does that also mean that after you start a Draw() call, you just let the GPU do work and while it's doing work, you just go to the next statement immediately?

EDIT: nvm, got your reply at http://gamedev.stack...der/28397#28397