GL_ARB_vertex_array_object2

Hi,

I thinking VAO could bit a lot better and allow fast buffer object switch.

From:


for(std::size_t i = 0; i < positionArrayName.size(); ++i)
{
  glBindVertexArray(positionArrayName[i]);
  glDrawArrays(GL_TRIANGLES, 0, VertexCount);
}
glBindVertexArray(0);

To:


glBindVertexArray(positionArrayName);
for(std::size_t i = 0; i < positionBufferName.size(); ++i)
{
  glActiveArray(GL_ARRAY0);
  glBindBuffer(positionBufferName[i]);
  glDrawArrays(GL_TRIANGLES, 0, VertexCount);
}
glBindVertexArray(0);

Or hopefully something more clever. I know how this “glActive***” idea becomes an issue for texture … even ifthe real issue is the mix of image and filter in a single object.

allow fast buffer object switch.

No such thing. So there’s no point in allowing it.

Why there is no point?

Let’s me picture you the use of it.

Let’s say we have a scene with 10 different meshes. Each object have position, texcoord and normals but different geometry.

This could allow to create a single VAO and just change the buffer(s) used for each meshes.

10 descriptions of how the buffer are use seams pointless to me, duplicate.

If you mean factoring the format into a separate object like dx10 does, that may not be strictly necessary for good performance. Probably the best overall usage is to minimize the number of objects you create and to avoid switching them, pretty much the way you’d deal with any other state…

Let’s say we have a scene with 10 different meshes. Each object have position, texcoord and normals but different geometry.

This could allow to create a single VAO and just change the buffer(s) used for each meshes.

Or you could have 10 VAOs. The latter is the one that is guaranteed to be the fastest, and VAO is all about performance.

Isn’t the whole point of VAOs NOT to change any state after setting it up once? So, they should give you the best performance (of buffer switching) exactly when you DO have the 10 duplicates, INSTEAD of changing their state.

Or did i miss anything here? I haven’t used that extension yet, but from what i read, i thought that would be the supposed usage.

Jan.

You haven’t missed anything, unless I’ve missed something.

Yes that’s the issue. Why creating pack of states and changing the pack of states when there are actually the same?

If the purpose is not to change states so share them to multiple buffers.

These VAOs are what I was expecting from the Long Peak format object, describ how to use array buffers and I guest this could lead to an extract benefit.

Why creating pack of states and changing the pack of states when there are actually the same?

Because they’re not the same. The buffer object is different. And the buffer object is part of the state.

And I would like buffer objects not part of the states but bind to slots. These slots would be part of the states. Couldn’t it be as efficient or even more with multiple buffers, a common senario.

And I would like buffer objects not part of the states but bind to slots.

Then you’re throwing away the performance advantage of using VAOs to begin with.

Really? Why?

Almost every states remain, what could VAO could make buffers to make them faster? With offset, format, stride, etc they get everything to access to a buffer. Yes, except the actually buffer address in memory. There is probably a cost for searching this address from the buffer name but that the same cost than searshing a VAO address from a VAO name.

I don’t believe that VAO would cache any part of the buffer, buffer data can be changed anytime. I won’t even believe that a specific computation could be done on the actual buffer address for the same reason.

Really? Why?

Because the binding of a buffer object to a vertex attribute is where the big performance penalty is. This is something that nVidia has gone on at length about. It forces the driver to do various checks and so forth that can be cached, and the VAO is where that caching takes place.

It doesn’t satisfy me enough, I’ll try to get more information on this buffer checks … Not sure I found get a lot …