View Full Version : render context with multi threading
10-24-2005, 02:38 AM
i've searched this forum for information about opengl and multithreading, but I haven't quite found the answer to my question.
I'm writing a server that renders a lot of different scenes for a number of clients. I'd like to create a thread for each client, so I would be rendering one scene per thread.
If I create one context per thread, will the OpenGL calls go to the right context? I don't want a call like glColor3f(1.0,1.0,1.0) in one thread to influence the drawing in another thread...
You must activate each context for each thread each time you change thread. It should have been discussed several times in those forums (did you tried to search on the advanced forum ?)
10-24-2005, 12:16 PM
i searched the advanced forum but didn't find a post about rendering multiple scenes in multiple threads.
You must activate each context for each thread each time you change thread. How would you do this? You don't know when the operating system will change the current thread...
10-24-2005, 12:56 PM
If you are using Windows, you should be able to just call wglMakeCurrent before doing any rendering. Do each of these threads render to their own window/control? And do you call your OpenGL calls from the same thread that created the context?
10-24-2005, 01:40 PM
I could call wglMakeCurrent before doing any rendering, but if windows decides to switch to another thread, right after the wglMakeCurrent call, I don't know what will happen (hence this question).
I'm not sure if I'll be rendering to a window or rendering to an off-screen buffer, but every thread will render to it's own window or buffer, and all OpenGL calls will come from the same thread that created the context.
Basically I want the rendering in each thread to be independent of the other threads as if they were all run in a different proces. I don't want to create a new process for each client. I'd like to know if this is possible. I don't really know if each thread has it's own context or if they share a context that's associated with the proces that created the threads. The red book and google let me down, so I hope someone can clarify this for me.
10-24-2005, 02:04 PM
It shouldn't matter if the CPU switches threads after you call wglMakeCurrent so long as all your rendering is done from the appropriate threads. (The threads you created the context in and called wglMakeCurrent in.)
The wglMakeCurrent function makes a specified OpenGL rendering context the calling thread's current rendering context. All subsequent OpenGL calls made by the thread are drawn on the device identified by hdc. You can also use wglMakeCurrent to change the calling thread's current rendering context so it's no longer current.
Note that it sets the calling thread's current rendering context. Once you set a thread's rendering context, it shouldn't change unless you call wglMakeCurrent again in that same thread with different parameters.
So, in my previous response you probably don't even need to set it before the rendering, just when it is created. In the opposite situation, rendering to multiple windows/controls from the same thread, you would need to use wglMakeCurrent at the start of any OpenGL calls for a specific window.
Is there some particular problem you are running into that prompted this question?
10-24-2005, 02:31 PM
I haven't run into problems.
I'll be developing a remote rendering architecture for my master thesis and i'm looking into different options (OpenGL, directX, ...) for rendering. I've been studying OpenGL and I wasn't sure how the OpenGL context behaves when multithreading. Global variables and multithreading aren't the best of friends and OpenGL seems to be somewhat of a 'global' state machine (it's obviously more sophisticated, but this was the reason for my concern).
I didn't find any decent information about this particular subject so this was my last resort :-).
Anyways, thanks a lot for replying so fast. You've been a great help.
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.