[Openmcl-devel] OpenGL and threading
mklarson at apple.com
Sat Jun 10 02:49:27 UTC 2006
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.
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.
> 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"
> 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-
>> and also did (in a listener):
>> ? (setup-opengl-context (same-context-as-background-thread))
>> that you'd have to provide your own locking/synchronization
>> - 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?
>>> 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
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel