Single VBO memory management and state change optimization techniques

[Dark_Photon]

@Erik9631

Basically from all the various sources that I have researched … there is one general recommendation to guarantee high performance in OpenGL and that is limiting the number of state changes.

No. No single change or combination of changes, whatever they are, will “guarantee high performance” in general, without any qualification of hardware, software, drivers, or technique.

I have managed to find a benchmark (From Nvidia), which I am not sure how up to date is, which shows various OpenGL operations and how expensive they are.

Possibly you refer to the one mentioned here?:

• Relative costs of state changes (PipelineLayout compatibility)
• vertexarray object, performance - #4 by Grognard

originally posted in this NVIDIA presentation here?:

• Beyond Porting: How Modern OpenGL can Radically Reduce Driver Overhead (2014, Slides; p. 48)
• Beyond Porting: How Modern OpenGL can Radically Reduce Driver Overhead (2014, YouTube; offset 31:56)

However I dug up a pretty large hole when it comes to managing state changes of a VBO. I have not found any reasonable documentation or benchmarks about how to do this efficiently and what is the considered to be the most “Modern, up to date method” of handling them.

Generally there are two approaches.

1. Use relatively many VBOs and bind them as appropriate (Letting drivers handle their memory management)
2. Use a single VBO per vertex attribute, bind it once and put all the data you need into it and draw it via multi draw commands.

These aren’t really the only choices, or even the best choices.

It seems you may be unaware of interleaved vertex attributes, or that buffer objects themselves are typeless. For instance, you can store all of your vertex attributes and index lists, for multiple batches, in the same GPU buffer object, with no problems at all.

The second case, as I mentioned earlier seems to be a massive rabit hole,

Sounds like you want to read this wiki page, if you haven’t already, and ask follow-up questions:

• Buffer Object Streaming (OpenGL Wiki)

That’s for handling efficient streaming of dynamic content to the GPU. For static content, you don’t really need this.

Needless to say, writing a fast and efficient memory allocator isn’t trivial and in practice,

True. But you really don’t want to go that route anyway.

Motivational blog post (that actually strongly related to your question):

• This One Weird Trick Let’s You Beat the Experts (Supnik, 2021-10)

But seriously, for dynamically uploaded content, just read that Buffer Object Streaming wiki page and ask questions.

What I find absolutely astonishing is there is literally zero documentation, zero discussion, zero anything about this.

You just haven’t tripped over it yet. There are chapters in books about some of this.

Two basic issues:

1. How to manage buffer object memory for vertex attributes and indices
2. How to issue draw calls sourcing from those buffer objects most efficiently.

From a performance standpoint, the cost of #2 is actually a driver for #1. **

Re #2, I can’t tell you how your GPU+driver performs, but you can run tests to determine cost per draw call in various scenarios. I can tell you that on NVIDIA GPUs, command lists and NVIDIA bindless are about the fastest ways to issue batches (draw calls) referring to VBO data. Behind that, it’s VAOs backed by VBO data and client arrays (depending on batch size). And often slowest, plain old unaccelerated VBOs. The larger your batches (draw calls), the fewer your draw calls, and the less the cost per draw call matters. But bottom-line is, you care about minimizing total draw call cost and overhead, especially if you have a ton of tiny batches.

Re #1, for static content, just pre-upload that on startup to whatever buffer objects you want. To the extent that you’ll batch draws for multiple objects together in shared draw calls, obviously you’d want to combine those in the same buffer object or objects (they talk about this way back in that 2014 presentation, for instance). For dynamically-uploaded content, see that Buffer Object Streaming page for a primer. In either case, you make those buffer objects as quickly accessible to draw calls as possible, to keep your cost per draw low. Minimizing draw calls by batching more content together can help reduce this overhead, to a point. But at some point you start trading culling efficiency.

** (There’s also the issue of how to dynamically generate this content on the GPU when needed, but we’ll assume you’re not doing that for now.)