- Is my assumption right that only the thread owning the OpenGL-context can allocate buffers? Or can I call glGenBuffers in the resource loading thread and use the object name in the rendering thread?
- When I have a buffer, is it the rendering thread that must call lock() and unlock() on it?
- After calling lock() and having a pointer to the buffer data, can only the rendering thread write to that memory?
- And finally, my current plan is to load the vertex data in a seperate array, then copy that to a vertex buffer on the rendering thread. It sounds inefficient to me, but is there any other (better) way?
Multithreading and OpenGL contexts,
Members - Reputation: 1400
Posted 19 November 2006 - 03:17 AM
Posted 19 November 2006 - 05:54 AM
Members - Reputation: 857
Posted 19 November 2006 - 08:57 AM
you can only execute OpenGL functions in a thread which has a valid OpenGL context. Therefore if your rendering thread has the context any GL calls in another other thread will fail.
While this is sort of true it's not accurate. Each thread has it's own current context. If you do not set the context in the second thread, the calls are likely to fail. However, if you create two contexts, and set one in each of the two threads just once (you don't need to swap between them, just set them from the correct thread) you should be ok.
Once the contexts have been created, you can call wglShareLists on the second one (After sharing, you set them to be current in either thread.) to share pretty much all objects between them. This includes textures, VBO, display lists. You can do anything with them in either thread, but I think you need to take care of multi-threading issues yourself, the driver generally doesn't (so you'll have to create your own locks on them). After calling glMapBuffer either thread should be able to write to the memory as it's been mapped into program memory space (not tested this).
a few threads discussing this matter:
my last post in the following thread is pretty much the most important one: