Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have simple application. It has two threads. Each thread has it's own rendering context, but they share one VBO (this is working, I tested it).

Now what I want: One thread is rendering some data from first half of VBO and the second thread is updating second part of VBO.

When I don't update VBO, it's working fine.

But I have some weird issues when updating. When I use glMapBuffer to update VBO (in second thread), it's most time rendering nothing (in first thread) - whole screen is clear (after glClear call). It looks like it can't touch data from VBO (this is understandable, because whole buffer is mapped and so it can be locked somehow).

I tried to use glMapBufferRange, which has flag GL_MAP_UNSYNCHRONIZED_BIT. This should mean: don't wait and use VBO as you want, I will synchronize it by myself. Also - when I map only range of VBO and render data from other part, it shouldn't be waiting. But there are the same issues as with glMapBuffer.

Can anybody explain why or help me, how to fix this? This is my first multi-thread OpenGL app :\

share|improve this question
up vote 6 down vote accepted

If someone is interested in this problem, you can find solution on OpenGL forum. Basically, buffers can't be accessed by two threads or contexts simultaneously, neither for reading nor writing. Therefore, a locking mechanism like std::mutex is needed.

share|improve this answer
Thanks for pointing to the solution. I edited your answer to summarize it. – danijar Mar 12 '14 at 20:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.