View Full Version : how to handle a multi-thread OpenGL program
my function like this:
I called it in several threads and let them execute consequently. I have several other data-processing threads without any display functions. But I get a "segmentation error"
when the first thread runn xxx, right after
Anyone here knows where my problem is?
might not be it. But when you using drawing functions in a thread, the RC to wich you draw have to be create in that thread.
all my threads want to draw in the same window. does it mean I cannot use a multi-thread program here? Or is there any way to get out of it.
segmentation fault is not due to opengl RC, because when you try to change some states, opengl checks if the RC (wich pratically IS opengl) is assigned to the calling thread.
if it's not, opengl discard changes.
it's just like if you don't call opengl function at all.
so, into a multithreaded application, every thread must have exclusive access to opengl, and since you have only one RC (normally) you have to manually assign it to the thread functions.
the function to handle thread assignement of RC under win32 is wglMakeCurrent().
note that when a tread owns a RC, it must be released by the same thread before it can be used by other threads.
PS: well, the way opengl behaves when a thread don't own the RC is a spec issue, but sometime specs are not followed correctly...
i can tell for sure that with MS generic and matrox g200 drivers it works this way.
other cards... don't know http://www.opengl.org/discussion_boards/ubb/smile.gif
[This message has been edited by dmy (edited 04-21-2000).]
04-22-2000, 05:27 AM
Isn't OpenGL getting confused too from having glBegin() calls from other threads simultaniously?
I mean, thread 1 calls glBegin(), some vertices (but not all) thread 2 gets the cpu, calls glBegin(), sends some vertices, thread 1 gets the cpu, finishes but the glBegin() was changed so OpenGL won't know the vertices apart and screws up?
It feels like a waste of time doing sync between threads that all want to render to OpenGL. It would be better (I believe) to have a dedicated rendering thread and other threads are just producing geometry data, culling and whatever.
OpenGL is a single pipeline - why use threads to render to it when it must be serialized anyway. It makes a point to do animation, application, culling and other stuff in other threads on a multi-CPU system. But not rendering, unless you render to separate displays.
as like some gl commands are not accepted after a glBegin(), i believe that opengl don't let the application change the RC assignement.
oh well, this is the way i would design it http://www.opengl.org/discussion_boards/ubb/smile.gif
i agree. it's a wate of processor time and developing time.
but not only rendering commands are not accepted in a Not-Owning-RC-Thread: every gl command is discarded!
into a NORCT you can't do:
-creation of display lists
Multithreading in OpenGL is more to do with either multiple outputs or segmentation of the physics calculations etc. In the first case you may have multiple windows with different RC's each handled by a single thread (Eg. CAD program...).
In the second your additional threads would perform AI and physics calcs simultaneously with another thread (the controlling one?) performing the rendering. This way you get the most out of the Rendering without the AI interfering with the speed (assuming the AI etc. ends up on another processor). The trick, as with all Multithreaded program. Is designing it write.
As an idea - however - what if you write to different buffers with each thread, and then a third thread combines the results? (If thats at all possible...)
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.