Imagination PowerVR SDK Blog

glBufferData and context sharing



I had the following plan for implementing an asynchronous buffer upload in an OpenGL program:

  • Create shared contextes. Render thread has one, worker thread has one.
  • Worker thread calls glBufferData. Each call allocates and uploads data completely fresh.
  • Render thread probes buffer upload state using fences. Once finished, it starts using the buffer for drawing.

My question now is: Will the glBufferData in the worker thread still affect the performance of the main render thread in some way even if the render thread does not use the unfinished buffer yet?

My fear is that commands from different contexts still end up in the same pipeline and that the syscall emerging from glBufferData will block the commands from the render thread. Or that a swapbuffer on the render thread causes a finish on the worker thread.




just to save a copy I’d use glMap(…) functions instead of glBufferData.

I don’t think glBufferData would affect performance of the main thread IF nothing depends on it in the main thread. If you have a draw call that needs that buffer it will wait.

OpenGL Insights has a great chapter on this topic:

You can use our PVRTune profiler to identify these sync issues. You’ll need an NDA though. You can contact us at to obtain one.



The reason why I use glBufferData is because allocation and initialization is at the same spot in the worker thread so I assume it didn’t matter.

Isn’t PVRTune part of the SDK?



glBufferData is not really optimal in any case these days as it has to allocate a fresh buffer every time, make sure that data is copied and only then it can return. It potentially blocks for long.
I’d just recommend using glMap(…)

PVRTuneDeveloper comes with our SDK installer. PVRTuneComplete (which is the one you need) has to be obtained separately.



But I need glBufferData anyways because I have to allocate memory and GLES doesn’t seem to have glBufferStorage yet. And since it’s in a worker thread, it shouldn’t block the main render thread, right?
I assume that you think I’m pooling things and want to reuse memory as much as possible.



oh right, well yea in that case only use it for allocation and suballocate (well map and manage) memory however you need it.