I’m sure I’ve seen this before but I didn’t turn up anything with ‘search’.
This question is in regards to all OS’s. ( Linux/Win/OSX)
IIRC you can make OGL calls from separate threads so long as each thread is rendering to a different context. Correct?
Is there the additional requirement that each thread must create the context that it is rendering to?
The 2 cases I’ve tried is single context (single window), many threads. Just make cxt current with wglMakeCurrent
2nd case : multiple windows, each in a different thread, each with it’s own context.
I don’t know about Linux and Mac.
On Windows, MSDN explains more or less but it’s quite ****ty.
If I am not mistaken, the threads have to create their own contexts…
The spec only says that a context can only be current in one thread at any time. This implies it can be current in multiple threads, as long as it’s not at the same time
I’ve so far only tested the case where each thread creates it’s own context, but I see no reason why it should not work otherwise.
Before making any gl calls in some thread, context MUST be current in that thread and NOT current in any other thread. Context can be created in any thread and pass it to another thread for usage.
Now… I have question. I have app that create 3 GL context. I would like to share objects between contexts. Im using wglShareLists call to do that.
Now… im confused… should I call wglShareLists for each pair of contexts (1-2, 1-3, 2-3) or just 1-2, 1-3?
Im getting strange GL errors (on first gl call) when I use 3 GL contexts with dualview setup on NV8600GT+C2D+XPSP2. If I use clone, span or single view mode everything works fine. Im not sure is it driver bug or Im mis-using wglShareLists.
For three contexts it’s enough to share(1, 2) and share(1, 3). In that case the objects of context 1 are the only ones left.
Note that the second hglrc parameter must not be current while calling sharelists and the first needs to be current, I think.
You should not have any objects in the second hglrc (the one which loses its object namespace) or the sharelists call could fail.
MSDN doesn’t put any restriction where the rendering contexts should be created, it just says a single rendering context cannot be current in two different threads.
This is what I have tried:-
- Create RC0 & RC1 in the main thread
- Create Thread0 & Thread1
- Make RC0 current in Thread0
- Make RC1 current in Thread1
- Render to both threads simultaneously
Note: I’ve had problems with wglShareLists in the above situation. If you dont share the rendering contexts you should be fine.
Windows OpenGL context documentation
A thread using an OpenGL context is not required to be the creator of the context. The creating thread must release the context before it can be attached by another thread.
We also have had problems with dualview mode failing to share textures created with automatic mip-mapping using the GeForce card/driver but working on a Quadro card/driver.
take a look at the following poster from SIGGRAPH 2006. Although it is about multi-core rendering it is exactly what you are looking for having a context per thread and render in parallel.
Parallel Multi-View Rendering on Multi-Core Processor Systems.
I don’t get what’s new in that ‘paper’, it just seems to be stating the obvious and doesn’t sound optimal. On hardware where you have multiple cores, but a single rendering pipe (1 gpu), isn’t this going to cause many unnecessary context switches (thread context switches)? Isn’t it more efficient in this scenario to render in series rather than parallel (ie. have a single thread responsible for rendering all views in series)?