[Openmcl-devel] OpenGL and threading

Fri Jun 9 20:57:28 PDT 2006

The problem code is the following, which no longer crashes, due to  
the placement of the context locks around the call:

   CGLContextObj ctx = CGLGetCurrentContext();
   CGLLockContext(ctx);
   if (nextTextureNumber == 0) {
     glGenTextures(BZ_MAX_NUM_TEXTURES, BZTextureIDs);
   }
   CGLUnlockContext(ctx);

But now, the texture does not seem to take effect.  I.e. the object  
appears un-textured.

The idea of keeping all OpenGL calls in one thread is a good one, but  
in this case, for example, loading a texture causes the above code to  
be called, and that can happen due to code from the listener.

I should probably take this off the list, as it's becoming an OpenGL  
issue, and not an OpenMCL one.

Regards,

Kaveh

Kaveh Kardan                 Chief Technologist
kaveh at hawaii.edu             Academy for Creative Media
(808)956-5302                University of Hawaii

> Date: Fri, 9 Jun 2006 19:49:27 -0700
> From: Michael Larson <mklarson at apple.com>
> Subject: Re: [Openmcl-devel] OpenGL and threading
> To: openmcl-devel at clozure.com
> Message-ID: <3AEE3F6B-C5D3-4BAD-92B9-446318B7604E at apple.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> 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
>
>
>
> ------------------------------
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>
> End of Openmcl-devel Digest, Vol 32, Issue 5
> ********************************************