VBO: mixing static and dynamic buffers

Hi,

I’ve just been thinking about how to use VBO with vertex data that has both static and dynamic components. I’m interested in minimizing the number of buffers created and the number of glBindBufferARB calls while rendering.

For instance, morphed geometry will require positions and normals to be updated, whereas color and texcoords are static. These would clearly benefit from being in two separate buffers.

If an object has multiple meshes, I can see the following working if the index buffer was per object, and static/dynamic vertex buffers per mesh:

BindBuffer( GL_ELEMENT_ARRAY_BUFFER_ARB, … );
for ( <all meshes> )
{
/* streamed data */
BindBuffer( GL_ARRAY_BUFFER_ARB, … );
VertexPointer( … );
NormalPointer( … );

/* static data */
BindBuffer( GL_ARRAY_BUFFER_ARB, … );
ColorPointer( … );
TexCoordPointer( … );

DrawElements( … );
}

Does this seem like a sensible methodology?

This is probably wishful thinking (and difficult without changing the current GL API), but it would be nice to be able to have one static and dynamic vertex buffer per object, and to bind both before the mesh loop, and use the glXXXPointer offsets to find the required vertex data.

Cheers,

Mark

My understanding of the spec is that you can have each array in its own buffer. I agree that it would “potentially” benefit from being in separate buffers, and would even say that it would “probably” benefit on some (possibly not yet existing) hardware, but I disagree that your example would “clearly” benefit from being in two separate buffers. I can imagine hardware and/or drivers that would suffer a performance hit from trying to access data in different types of memory, for example. I’d recommend profiling the separate buffers approach on a variety of hardware and comparing it to a single, purely dynamic buffer on the same set of hardware.

Hi

I also have some problems in gaining speed by using vbo over simple vertex arrays.

I tested static indices and static texcoords with streamed positions and normals against static indices and streamed texcoords, positions and normals. I also tested indices without VBO but in all cases VBO was around 5%-20% slower than plain vertex arrays.I use a GF4 Ti 4600 with 43.30 drivers.

I rendered a heightfield with 1024 glDrawElements calls with each 2084 triangles.I got around 8FPS (–> 16Mtris). Thats a little bit low I think. Perhaps I should rearrange my indices and insert degenerate triangles, but what do you think ?

Bye
ScottManDeath

The nVidia guys have mentioned, on several occasions, that their implementation of VBO is only prelimiary. It doesn’t have much in the way of optimizations yet, so it’s not going to be particularly fast. Wait for actual release driver support for the version that is on-par with VAR performance.

Please do keep static and dynamic vertex data in separate buffers. This is exactly the kind of thing that will help the driver avoid extra data copying. The driver may need to make multiple copies of the static data for most efficient rendering, but the fact that the driver knows it’s static makes keeping “shadow copies” an option.

The overhead of using multiple buffers should be insignificant, but it probably is a good idea to keep data that varies at the same frequency in a single buffer.

It may take a little time before we get detailed performance FAQs on VBO usage out there, but the design of the API is intended to make it easy to hit the fast path. Current drivers are no indication of what the optimized implementation of this extension will perform like. This support is available today primarily for beginning the porting process.

Thanks -
Cass

Should I prefer ARBvbo over single glVertex/glNormal/glColor-calls even for completely dynamic data changing from frame to frame? Only the values change (e.g. vertex positions), not the number of vertices to draw.

Hampel

Yes, prefer ARBvbo under most any circumstances. It won’t be slower, and it could be a lot faster.

Cass

Try the new 43.45 drivers with VBO - they give a lot better performance than the 43.00 set.

Mark

Does the pointer to a mapped buffer object remain valid, if I make another OpenGL context current?

Yes, it should.

I just installed the 43.45 drivers. Any ideas why ARBvbo does not show up in the extension string? Did I miss something here? System is WinXP, Ti4200. The right set of drivers show up in the device manager (i.e. 43.35).

  • HM

ARBvbo is not in the extension string because the functionality has not been fully tested. The entry points can be initialized, and the extension should work, but we won’t put it into the extension string until we have done more testing.

Thanks -
Cass

Originally posted by cass:

ARBvbo is not in the extension string because the functionality has not been fully tested. The entry points can be initialized, and the extension should work, but we won’t put it into the extension string until we have done more testing.

I commend you on your policy. It solves the chicken and egg problem pretty well: The extension is not supported because it has not been tested, the extension has not been tested because it is not supported.

I’m running the (newest) 41.91 drivers on Linux. I was not able to initialize the entry points. Is the extension not supported or am I doing something wrong? I thought I had read that it isn’t supported until the 43.00 drivers. If so, is there a general timeline as to when those drivers will be available for Linux?

Originally posted by PK:
I’m running the (newest) 41.91 drivers on Linux. I was not able to initialize the entry points. Is the extension not supported or am I doing something wrong? I thought I had read that it isn’t supported until the 43.00 drivers. If so, is there a general timeline as to when those drivers will be available for Linux?

Hi PK,

The extension is definitely implemented in pre-release Linux drivers. The Linux driver release schedule is often out of sync with the Windows driver release. The next public Linux driver release should have VBO support, though. Sorry for the inconvenience.

Thanks -
Cass