11
\$\begingroup\$

I have a simple application. It has two threads, each with its 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 the first half of the VBO and the second thread is updating the second part of the VBO.

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

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

I tried to use glMapBufferRange, which uses GL_MAP_UNSYNCHRONIZED_BIT. This should mean, "don't wait and use the VBO as you want, I (the program) will synchronize it by myself". Also, when I map a range of VBOs and render data from another part, it shouldn't be waiting, but I'm experiencing the same issues as I am with glMapBuffer.

Can anybody help me fix this or explain why it happens?

\$\endgroup\$
6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Thanks for pointing to the solution. I edited your answer to summarize it. \$\endgroup\$ – danijar Mar 12 '14 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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