[Openmcl-devel] OpenGL and threading

[Michael Larson]

We recommend applications have a separate drawing thread or use mutex  
locks when sharing a OpenGL context between multiple threads.

Developers usually implement a single drawing thread which reads a  
custom display list embedded with drawing higher order primitives  
rather than simple primitives like quads and triangles.

I am too lisp ignorant to provide an answer on how to do this, I am  
sure there multiple ways to do this.

I would like to find the time someday to do some opengl lisp hacking,  
if there are simple examples to start with send them my way.

Mike Larson
Apple OpenGL


On Jun 9, 2006, at 5:29 PM, Lawrence E. Bakst wrote:

> This was recently discussed on the mac-opengl list. I copied some  
> relevant excerpts below. Hope this helps.
>
> Best,
>
> leb
>
> At 5:21 PM -0400 6/6/06, David Duncan wrote:
>> OpenGL is threadsafe in-so-far that you can call the APIs from  
>> multiple threads at the same time. However you cannot be in the  
>> same OpenGL context on two different threads, that is not  
>> threadsafe and will require you to do your own locking. You can  
>> configure the context on one thread, then use it on another thread  
>> (I've done this for the same reason myself) and then you don't  
>> need any locking either, as long as you take care not to touch the  
>> context on both threads at once.
>> --
>
> At 4:59 PM -0700 6/6/06, Chris Niederauer wrote:
>> I should have also mentioned that we added new API in 10.4 that  
>> allows NSOpenGL contexts to be used with multithreading by calling  
>> CGLLockContext and CGLUnlockContext around all of your OpenGL calls.
>> It can be used outside of NSOpenGL as well, if you'd like.
>>
>> You can read up on multithreading and OpenGL in our new OpenGL  
>> Programming Guide for Mac OS X in the "Multithreading and OpenGL"  
>> section:
>> <http://developer.apple.com/documentation/GraphicsImaging/ 
>> Conceptual/OpenGL-MacProgGuide/>
>
>
>
>
> At 6:14 PM -0600 6/9/06, Gary Byers wrote:
>> This is more of a stab in the dark than a suggested workaround, but
>> the stab worked a few weeks ago and seems worth another try ...
>>
>> OpenGL contexts are bound per-thread; if a given thread hasn't
>> established a context (via some Cocoa/AGL/GLUT mechanism), then
>> any OpenGL call made in that thread that requires a GL context
>> will crash and burn (and segfault.)
>>
>> I -think- (and I'd have to read the docs and double-check) that
>> GL is otherwise not thread-safe in and of itself; that if you
>> did something like:
>>
>> ? (process-run-function "background GL thread"
>>      #'(lambda () (setup-opengl-context ...) (some-sort-of-event- 
>> loop)))
>>
>> and also did (in a listener):
>>
>> ? (setup-opengl-context (same-context-as-background-thread))
>>
>> that you'd have to provide your own locking/synchronization  
>> mechanisms
>> - or depend on luck - to avoid problems.
>>
>> (It would be good if I was mistaken about that.)
>>
>> On Fri, 9 Jun 2006, Kaveh Kardan wrote:
>>
>>> I'm calling an OpenGL-based library from OpenMCL, following the
>>> example given in the distribution.  The example runs OpenGL/GLUT  
>>> in a
>>> thread, so that the listener can be active.
>>>
>>> The problem I'm running into is any interactive code which invokes
>>> OpenGL calls (and is therefore not running in the same thread as the
>>> OpenGL process), causes a crash.
>>>
>>> Does anyone have a suggested workaround?
>>>
>>> Regards,
>>>
>>> Kaveh
>>>
>>> Kaveh Kardan                 Chief Technologist
>>> kaveh at hawaii.edu             Academy for Creative Media
>>> (808)956-5302                University of Hawaii
>>>
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel