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?

Improve this question
\$\endgroup\$

1 Answer 1

Reset to default
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.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ Thanks for pointing to the solution. I edited your answer to summarize it. \$\endgroup\$
    – danijar
    Mar 12, 2014 at 20:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .