# Techniques for managing vertex buffer memory

I'm learning OpenGL and I haven't seen any advice on managing vertex buffers in all of the tutorials I've read.

The basic problem is that I have some memory allocated as a buffer B in which I'm going to store vertex data to send to the graphics card.

Then I have the data that represents my domain D. This is the data that the game's simulation is run against. Let's say in a simple case it's just a list of 100,000 circles that will be moving around. Let's also assume that all of the data can, but might not, change every frame. Nothing is necessarily static.

I'm looking for the techniques people use to efficiently fill B with D.

I could create a new B each frame, but I imagine that would be very expensive.

I could give every object in D a pointer to a location in B and have it update that pointer directly, but that strikes me as error prone as then I have to manage all of these pointers.

I could also traverse D and fill a reused B every frame. This is what I'm currently leaning towards. The only problem here is that I'm forced to update every vertex in B every frame (because the location of the vertex data for a particular D could change within B) unless I come up with a more sophisticated scheme that guarantees that that an object in D always gets the same spot in B.

So I can think of several options, but I'm wondering what people typically do. I imagine almost everyone has to solve this problem at some point.

• Your solutions get progressively less attractive to me, because each one suggests modifying part of a buffer that is more likely to be queued up for use in another command that has not finished yet (e.g. the frame the GPU is currently processing). That introduces implicit synchronization overhead in the driver to prevent modifying memory that has not been used yet. It sounds to me like you are looking for a general strategy for efficient buffer streaming, I do not know how technical you want to get with this, but you could start here. – Andon M. Coleman May 14 '14 at 22:04
• I suppose the answer is that I want to get as technical as I need to. Thanks for the link. I read it and some other related sites and I think I understand what you're saying. I don't want to modify the buffer with new data, because I have to wait for OpenGL to be done with it, meaning I can't update/render in parallel. Does that mean that creating a new buffer every frame is really my best bet? Should I create a set of buffers and cycle through them? The site you linked me to lists downsides for all of its proposals. Is there no commonly accepted solution? Is it unique to every application? – Twernmilt May 14 '14 at 23:30
• Very generally, if you read that link in the order it is written, each of the things introduced requires a newer and newer version of GL. Buffer orphaning (creating a new buffer data store each frame) or multi-buffering are the most portable. Multi-buffering is difficult to implement correctly though, because it is hard to know for sure how many frames worth of data updates are still pending - NV often suggests using 3 buffers as a minimum (1 for active GPU execution, 1 for a queued frame and 1 for the frame the CPU is currently setting up). – Andon M. Coleman May 14 '14 at 23:53
• I always find relevant knowing how successful games do it. Take a look at the source code of Doom3, they have a double buffered "VertexCache": github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/… – glampert May 15 '14 at 3:19

In any case, you should be trying to reduce the time it takes to translate D to B as much as possible. I would suggest architecting D in a data-oriented way - contiguous and using a structure-of-arrays design rather than array-of-structures - so that you can boil it down to a few straight memcpy()'s.