OpenGL threaded loading

Question

I'd like to introduce seamless level loading which means I need multiple threads. The main thread is for rendering the current scene (or for non-seamless level loading a progress bar) while the other thread is loading the resource files and sending data to the graphics card.

Now I have the following single threaded architecture: when the graphics device is initialized, a dummy window and a "shared context" is created. This is the only rendering context (HGLRC in Windows terms) I'm creating. Every time a new window is created and the graphics device is asked to create a "renderable surface" into that window, the same "shared rendering context" is used. I can do this because I set the same pixel format for each window, so there is no point to make multiple rendering contexts (that would just make my life harder than it should). Here is a small image representing the current design:

I've read some topics about this but now I'm confused since I read really different point of views, so I have some questions:

• As far as I know an OpenGL context can be active in a single thread only (at a time). This means that I need another "loading rc" which shares resources (through context creation or *glShareList) with the "shared rc". Every time I create a new thread to load something, I have to set the "loading rc" active in that thread. Am I right?
• Can I use the same dummy device context (HDC) in the loading thread?
• Because I have a single GPU the commands sent to the graphics card are queued up. Right? Will this behaviour introduce switches between shared and loading contexts?
• Is there anything else I should take care of?

Answer 1

1. Each OpenGL context can only be "active" in a single thread at a time.

If you wish to be making OpenGL calls from two threads simultaneously (as in your example of one "loading thread" which is creating textures, VBOs, etc), and one "rendering thread", then as you say, you need to create a second context, with shared data between the two contexts.

Do note that shared contexts do not share all OpenGL data. Particularly notable exceptions are FBOs and VAOs, which will remain only in the context where they were created.

2. Yes, you can create multiple OpenGL contexts referring to a single window (HDCs, on Windows OS).

3. You are given no guarantees about what order the commands given to shared OpenGL contexts will be handled.

If you wish to make use of data inserted into one shared context from the other context, you'll need to put a fence in, to make certain that the data is definitely in sync between the two contexts before you try to use it. For example, if you want to draw something which has just finished loading, then you'd want the loading thread, after it has finished loading its data and pushing it into its shared context, to do something like this, before signalling the main thread that it's okay to draw the loaded data:

GLsync fenceId = glFenceSync( GL_SYNC_GPU_COMMANDS_COMPLETE, 0 );
while(true)
{
    result = glClientWaitSync(fenceId, GL_SYNC_FLUSH_COMMANDS_BIT, GLuint64(5000000000)); //5 Second timeout
    if(result != GL_TIMEOUT_EXPIRED) break; //we ignore timeouts and wait until all OpenGL commands have been processed!
}

4. The common wisdom is that you're generally a lot better off using only a single context, rather than two shared contexts.

Instead of making OpenGL calls directly from a second thread via a shared context, the usual advice is to instead simply prepare data from that second thread, but actually perform all the OpenGL calls from the main thread. Drivers, they say, are generally much better-optimised for the single-context case, and it's worth trying to fit the way the drivers want to work, rather than do anything complicated and weird, like shared contexts.

So it's worth considering whether you really want to go down this path. It gets complicated fast, and you pay a performance penalty for every extra shared context, even when you're not actually using them.

Answer 2

The short answer: No!

Don't do that. Just, don't.

The slightly longer answer

Unluckily, OpenGL does not truly (contrary to folklore) support multithreading. No, really, it does not.

You are of course aware that a context can be (must be) active for exactly one thread using that context, and making a context current between threads effectively causes lockstep behavior and is horribly expensive.

Now, sharing two contexts (with one context each bound to one thread) sounds like it would give you just what you want. However, this is an illusion.

Sharing contexts will significantly degrade overall performance due to internal synchronization and will be slower than just doing everything in one thread.
When I tried this some years ago, sharing contexts, even if there were no changes made (so, really nothing to synchronize!) would cause an approximate 8-10% performance drop compared to using a single context and a single thread. Maybe drivers have somewhat improved since then, but I would not rely on that since sharing contexts is not a very commonly used feature, and not a top priority.

The somewhat less pessimistic answer

There is still a way to get some parallelism into that beast. You can map buffers in your render thread, pass a pointer to a worker thread, and have the worker thread fill the buffer with data. Then, signal a condition variable, causing the render thread to unmap the buffer again ready for use. You still have the mapping/unmapping on your render thread, but at least you can offload the shuffling around (and loading from disk, unpacking) of data.

Be sure to use a technique like buffer orphaning (or use the copy write buffer) and the unsynchronized bit to avoid unnecessary stalls on modifying buffers that are still being read from and client/server syncs. Unluckily, even unsynchronized maps will have some syncs that are unavoidable.

If updates are frequent (probably not the case in your example) and persistent mappings are supported, you may want to use these, making the repeated mapping/unmapping unnecessary. Just map once and pass a pointer. Be aware that persistent mapping is slightly slower overall, so it's only advantageous if you have frequent (every frame, or nearly so) updates where the cost of mapping/unmapping is dominating.