OpenGL driver question.

[christiancoder]

Does the OpenGL driver use threading internally to improve resource object buffer writes? The reason I ask is my texture/vbo writes don't take as much time as I would expect, but subsequent draw calls that use the updated resources seem to spike (perhaps blocking while waiting for the resource write to finish). I am profiling on MacOS 10.6.3 with a GF9400. I was about to write some code to use a shared context and a separate thread to write resources, but it seems that this will likely be a waste of time.

Actually after more observation it looks like when resource object buffer data is written it is cached in a dirty state until a draw call requires it. So the first draw call that uses a dirty resource object causes a spike, is this correct? Is there a way to flush resource objects so that subsequent draw calls will not stall? Basically I am in search of the smoothest async way to stream in new assets so that later draw calls that use the new assets don't stall.

[ZbuffeR]

resource object buffer data is written it is cached in a dirty state until a draw call requires it.

AFAIK, it should not be the case when streaming VBO or PBO.

However, you may use the updated data too early, as the async transfer may not be finished yet. A single frame delay should be enough to fix this.

[kyle_]

Wouldnt simple glFlush() help you out there (if caching is indeed your problem, and not too early usage)?

[Rosario Leonardi]

Sending command directly to the GPU is slow cause it require a syscall, that's why a lot of driver implement marshalling.
They put all the command in a queue and then execute the commands when the queue is full or when explicitally requested (by glFlush, glFinish or swapbuffers).

If you want async loading one way is to use a second context in a separated thread with shared resources.