Dynamic VBO. Does one do it? Scheduling

I am wondering if all dynamic data is equal. One big VBO for every call? Will it be scheduled. Or is there some black magic to having dynamic VBOs for different model data that will be rendering/updating at different times? I cannot find anything on this subject. Thanks.

(I don’t know if this is forum appropriate. I am just working on rewriting the original COLLADA-DOM viewer/browser package, so I have an account in the COLLADA forum.)

EDITED: Please don’t post to say “try both ways and see.” I’m asking because I don’t want to do it both ways. The answer will affect how I will try to cope with COLLADA’s unique indexing challenges.

Since you’re posting on the OpenGL ES forum, I’ll assume you want a mobile perspective.

From having used a dynamic VBOs on a mobile GPU, I can tell you that it is doable but it can be tricky.

As to VBO size… Binding is expensive. The less you do, the better. This argues for larger VBOs.

That said, you always have to keep in mind “do I have a batch in-flight which references this buffer object already”. If the answer is yes, then updating the buffer object contents from the GL-ES API will “normally” (see ** below) cause the GL driver to either:

  1. stall (until the GPU finishes pending work referencing the buffer contents) or
  2. make a copy of the buffer object with the prior contents (aka resource renaming, mirroring, ghosting, etc.)

Both are inefficient. Which one happens depends on the GL driver (see your GPU vendor for details). This driver detail is common for tilers, and it “normally” (**) argues for smaller VBOs. However…

** The exception to this stalling/mirroring behavior is if your driver supports unsynchronized maps properly (see Buffer_Object_Streaming#Buffer_update in the OpenGL Wiki). In this case, you can bypass the stall and copy, allowing you to stream dynamic content into one or a few large VBOs, while the GPU+driver continues to render from other areas of the VBO that you’ve previously populated.

If your driver supports this, it’s certainly practical to create one or a few big VBOs, stream your batch data into them, and render it directly from there while the GPU+driver is reading from it elsewhere.

If your driver doesn’t support this, then to keep the one or a few big VBO concept, you need more VBO memory (to avoid stalls/copies). You have to ensure you’re never updating a VBO referred to by an outstanding batch.

Thanks for the speedy reply. I thought I checked this daily for some days after posting. Sorry for disappearing.

I appreciate the practical information. I think it will take longer to send the data over the bus than to display it. If so, and it’s send,draw,send,draw, I don’t see conflicts except for waiting to draw. Maybe just juggling a few small VBOs is good, except for if as you say the bind step is costly.

A big VBO is not a problem, except it uses up video memory that other applications can use, and in theory could run up against limits.

I’m not personally concerned about performance as long as it’s nothing pathological. But like I say, I couldn’t find discussions of the subject, so with any luck others may find this discussion helpful. (If it shows up in web search results.)

(There really should be some guidelines in OpenGL’s API reference.)

The API comes from the spec, and the spec specifies behavior, not performance and thus not guidelines for good performance.

Also keep in mind you’re posting in an OpenGL ES forum, not an OpenGL forum (those are here: Khronos Forums - Khronos Standards community discussions). The GPUs driven by OpenGL ES are very different from those typically driven by OpenGL. They’re much more picky with how and when you update things like buffer objects and textures. Re sending data over the bus, with mobile and GL-ES there typically is no bus (besides memory bus) as the GPU often shares memory with the CPU.

Thank you. Many applications are built on ES and non-ES platforms. I don’t think the distinction is so relevant. (Embedded systems are expected to under perform.) Personally if I have to use OpenGL I prefer ES. But it’s not really available for desktop platforms. (Sometimes emulating is worthwhile, sometimes not.)

I do appreciate the assistance. I know you’ve been a regular in the OpenGL forums for a very long time :slight_smile:

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.