🔒 Locked

Dynamic Vertex Buffers!

Started by adder_noir Oct 20, 2011 at 8:01 PM 3 replies 2.5k views

Original Post

Oct 20, 2011 at 8:01 PM

Hi!

The engine I'm working on - which I'm almost getting to enjoy - has a part of it that uses a dynamic vertex buffer. It stems from the days of AGP graphics cards. As far as I know that has now been surpassed long since by PCI-Express cards.

A dynamic vertex buffer is a kind of temporary buffer which is created in the AGP ram between the CPU and the GPU. It has the advantage of being fast, yet has the drawback of having to be rendered every frame whether the vertices have changed positions or not. You can, for example use them for models where the vertices deform. You could I suppose use one to deform a vehicle that was crashing or maybe make a nice waterfall with one.

They are also used for animations which again has now been surpassed by using shaders to do the animations.

Why am I asking? Well the engine I'm working on is old, but my word it's teaching me alot. I've successfully updated it to use effect files over the old assembly method it once used. Not an easy task for an intermediate programmer but anyways it's done now and touch wood is all nice and clean too with no memory leaks or problems. When running in debug mode the program exits normally which I hope is a good sign all memory has been properly taken care of which I've tried to ensure with the constructor and destructor. Learned a few things about variable initialisation I can tell you!

Anyways, dynamic vertex buffers are a huge part of the vertex manager class in the engine. The original author even used a method of catching render calls and delaying them so they could be sorted into little mini caches based on the texture (or was it the material? - can't remember) they were using. This meant instead of rendering a few triangles you rendered maybe a couple of thousand per render call, even if the render calls in the application weren't all made at the same time.

What I want to know is:

1) Can I completely do away with dynamic vertex buffers given the presence of PCI-E in the modern age or should I keep them in case they are needed?

2) Are they even still supported by modern releases of DirectX 9.0 and onwards?

Would be most helpful to know cheers

Krohm

Oct 21, 2011 at 6:25 AM

1) Can I completely do away with dynamic vertex buffers given the presence of PCI-E in the modern age or should I keep them in case they are needed?

The model you have built in your head is incorrect. DYNAMIC buffers are not dependent on the factors you mention. The transition from AGP to PCIEx does not change much in the logical model (I don't even get the notion you're trying to convey here). While PCIEx makes bidirectional transfers way more efficient the usage is not fundamentally changed.

All buffers always have the drawback of "having to be rendered every frame whether the vertices have changed positions or not". This reminds me of an old OpenGL feature called "compiled vertex arrays". I don't quite get where you got this idea, it was declared obsolete... like... 12 years ago?

2) Are they even still supported by modern releases of DirectX 9.0 and onwards?

Yes, they basically help the driver in understanding and positioning data for better DMA transfer or sharing memory address space for repeated write (or read).

The original author even used a method of (A) catching render calls and delaying them so they could be sorted into little mini caches based on the texture (or was it the material? - can't remember) they were using. This meant (B) instead of rendering a few triangles you rendered maybe a couple of thousand per render call, even if the render calls in the application weren't all made at the same time.[/quote](A) this is still a good idea. Some users actively suggest to use this method. In regard to this, Hodgeman's post are typically very informative, try looking them up. You will also find a link to an AAA game using this technique. Personally I'm not very much on it.
(B) This would require rebuilding IB and VB each time... or only IB at the very least. I don't know if this is going to work... maps are pretty slow IMHO. But I am interested in hearing opinions.

adder_noir

Oct 22, 2011 at 12:57 AM

Thanks for the reply.

That's a very detailed and technically accomplished post which I have to read quite a few times to understand. Some of it to be honest I don't understand neither am I ever likely to in truth.

I'm afraid my knowledge is limited only to that which I have read from the author of my book. In it he describes dynamic buffers as:

1) Being created and stored somewhere between the CPU and the GPU on the bus.

2) Somehow being connected to the concept of AGP but this now appears doubtful.

3) Something that has to be copied over the bus from their location to the GPU every frame even if the vertex positions haven't changed.

That's as much as I know. Reading your writings it appears they are still valid and still in use and I think that is as much as I would ever need to know, therefore I will keep them as part of the engine.

Thanks

Krohm

Oct 22, 2011 at 8:32 AM

1. It's likely. It really depends on implementations. Some implementations might map video memory right away. I'd expect most to pool the data somewhere to allow packing it in the command stream.
This is the whole point of marking something DYNAMIC (you might find D3D1x terminology easier to understand).
You tell the driver: "Please take notice I might need to write this resource's contents multiple times".
The driver mangles this information (or perhaps not, but that's not really relevant: it has the chance to) and figures out: "hey, as the user need to write this, I might want to manage this differently"

Driver A might say:
Let's reallocate a bunch of bytes! When I'll be asked for a map, I'll return a pointer to this instead of the real resource, switch a flag and update at the most convenient time.

Driver B might say:
I don't really care. I'll just map this piece of VRAM to virtual address space and let you write to it.[/quote]There are a few options. FYI, this example is probably oversimplified. I don't want to go in the details, just to put you in the right perspective.
Other users might probably provide more insights on the inner workings of the various drivers - drivers can also switch behavior to match the intended performance.

Whatever a driver does A or B... or something else... it's not really important conceptually: the important stuff is giving the driver the chance to better drive its management.

2. Minor difference. When it comes to discrete parts, they have to be connected somehow. Those components were once connected by AGP. They are now connected by PCIEx. It does not change much really - logically speaking - data will have to go through this tiny pipe connecting system RAM to VRAM or RAM to GPU.
This changes quite a bit for integrated architectures (it has always been that way). If a video adapter has no VRAM then no data copy will need to be performed and the data will already be in the correct spot. With the introduction of on-die GPUs, there are even more trade offs.

3. It's very likely. Notice your wording has changed. That's not a problem with DYNAMIC per se, but rather a problem with Map. I'd expect most drivers will just trust your application when you map a buffer and trash previous state.
Of course, the contained data, whatever it's changed or not[size="1"]{when} will still have to go through the whole pipe; it will be fetched to vertex processing, rasterized, shaded and ROP'd. You cannot do much to avoid this[size="1"]{hope}.

[size="1"][when] For immutable stuff that's guaranteed to be always not changed. For dynamic stuff, it is changed if it has been mapped since last frame.
[size="1"][hope] It is possible to transform only once by using pass-through vertex shaders (just copy input to output). It is also possible to reduce the number of rasterized triangles by using render-texture... hopefully you won't need to do this any time soon.

adder_noir

Oct 22, 2011 at 5:59 PM

That's a really good reply which has given me more idea what's going on and how much of it I really need to know about.

Thanks so much I voted you up

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.