I'm using a single VAO and switching multiple VBOs.

VAO are intended to be a light-weight set of bindings. The whole point is that you can cheaply keep one around for each VBO setup, to avoid having to re-bind the VBO each draw call.

Instead, you are keeping a single VAO around, and paying the rebind cost every single draw call. This makes no sense to me.

In practice though I tend to believe in what I see and not what I "think" makes sense.

Sure, various drivers don't derive any measurable performance benefit from VAOs. There are also still drivers where immediate mode + display lists are still the performance path.

Which is why I'd rather you weren't handing out advice based on generalizing results on a limited set of hardware/drivers.

In more practical terms it's going to be easier for you to make use of the GL_ARB_vertex_attrib_binding extension.

The problem with a traditional setup is that the buffer specified by glBindBuffer call is latched state. glBindBuffer on it's own doesn't do much at all; it just provides a way to signify to future GL calls which buffer you want them to use. In terms of vertex specification, what this means is that the glVertexAttribPointer call is the one that actually picks up the currently bound buffer and makes it part of the vertex attrib state.

The impact of this is that you can't just change your buffer (via glBindBuffer calls) and expect everything to work: you need to reissue a full set of glVertexAttribPointer calls too.

Sometimes that's what you want (or need to do), but in cases where you just want to change the buffer but leave everything else the same, vertex attrib binding provides a mechanism for it.

So, as a one-time-only step you create and bind your VAO then issue a set of glVertexAttribFormat and glVertexAttribBinding calls.

Then when drawing all that you need is to re-bind your VAO and issue glBindVertexBuffer calls to specify which buffer(s) are using. That's a perfect fit for the use case outlined in the OP.

If you're an advocate for VAOs then that's fine and I don't have anything against them. If they have a real world impact then I'm all for it but why dismiss a valid point that the benefit is not always there?

If you had reproducible data demonstrating that correct use of VAO resulted in decreased performance, I wouldn't have a problem with your statement.

But since your data indicates it to be a wash in your case, and existing benchmarks note measurable performance gains, I'd prefer that we continue to teach best practices.

There is contradictory information regarding multiple VAOs vs one single VAO and rebind.

• Data backing up multiple VAOs.
• Data backing up one global VAO.

Now, there is a 3rd option: AZDO. Azdo is about using one huge single VBO (or very few of them) and manual manipulation using unsynchronized mapping and fences (it's very Mantle-like behavior). Then place all the meshes in the same VBO at different regions (offsets) of the memory. When you've exhausted the VBO pool, create another VBO.

Because there are very few VBOs, now VAOs become more a matter of a "vertex format layout" specification, so you would only need one VAO per vertex format (still accounting there can be two VAOs for the same vertex format if you end up needing a few more vbos).

If you sort your draw calls by vertex format, the draw call overhead approaches zero, as you barely will need to switch vaos or vbos (or respecify any attribute).