Multithreaded Rendering on OpenGL

18
votes

I have a multithreaded application, in which I'm trying to render with different threads. First I tried to use the same Rendering Context between all threads, but I was getting NULL current contexts for other threads. I've read on the internet that one context can only be current at one thread at a time.

So I decided to make something different. I create a window, I get the HDC from it and create the first RC. AFter that, I share this HDC between threads, and in every new thread I create I obtain a new RC from the same HDC and I make it current for that thread. Everytime I do it, the RC returned is always different (usually the previous value + 1). I make an assertion to check if wglGetCurrentContext() returns a RC, and it looks like it returns the one that was just created. But after making the rendering, i get no rendering and if I call GetLastError() I obtain error 6 (invalid handle??)

So, does this mean that, despite every new call of wglCreateContext() gives me a new value, somehow it means that all these different values are the same "Connection channel" to the OpenGL calls?

Does this mean that I will always have to invalid the previous Rendering Context on a thread, and activate it on the new one? I really have to make this sync all the time or is there any other way to work arround this problem?

5
c++windowsmultithreadingopenglrendering
googled 2 pages which could help: higherorderfun.com/blog/2011/05/26/… and opengl.org/discussion_boards/showthread.php/… – Vitaly Dyatlov
well I'm doing something really similiar to that, but I'm getting Error 6 after wglShareLists call – filipehd
I think the question should also read as "Since multithreaded DirectX 11 rendering is faster than single threaded, can the driver bring the same improvements from OpenGL calls as well ?" – RelativeGames

5 Answers

55
votes

I have a multithreaded application, in which I'm trying to render with different threads.

DON'T!!!

You will gain nothing from trying to multithread your renderer. Basically you're running into one large race condition and the driver will just be busy synchronizing the threads to somehow make sense of it.

To gain best rendering performance keep all OpenGL operations to only one thread. All parallelization happens for free on the GPU.

14
votes

I suggest to read the following wiki article from the OpenGL Consortium.

In simple words, it depends a lot on what you mean for multi threading in regards to OpenGl, if you have one thread doing the rendering part and one (or more) doing other jobs (i.e. AI, Physics, game logic etc) it is a perfectly right.

If you wish to have multiple threads messing up with OpenGL, you cannot, or better, you could but it will really give you more troubles than advantages.

Try to read the following FAQ on parallel OpenGL usage to have a better idea on this concept:

http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html

5
votes

In some cases it may make sense to use multiple rendering contexts in different threads. I have used such a design to load image data from filesystem and push this data into a texture.

1
votes

OpenGL on Mac OS X is single-thread safe; to enable it:

#include <OpenGL/OpenGL.h>

CGLError err = 0;
CGLContextObj ctx = CGLGetCurrentContext();

// Enable the multi-threading
err =  CGLEnable( ctx, kCGLCEMPEngine);

if (err != kCGLNoError ) {
     // Multi-threaded execution is possibly not available
     // Insert your code to take appropriate action
}

See: Concurrency and OpenGL - Apple Developer

And: Technical Q&A QA1612: OpenGL ES multithreading and ...

0
votes

https://www.imaginationtech.com/blog/understanding-opengl-es-multi-thread-multi-window-rendering/

When shouldn’t I use multi-threaded rendering?

When you’re not CPU limited or load times are not a concern.

So, if you are CPU limited, separate other threads to do CPU limited job, such as codec, texture upload, calculate...