We are aware of an issue in the version of OpenGL Profiler that
shipped with Tiger where you will sometimes "catch" false thread
conflict errors around CGL calls when you use the "Break on thread
conflict" feature. If you are only using one thread to talk to your
carbon based OpenGL application, this "error" is likely something you
can ignore.
I might as well take this time to give an overview of thread safety
with OpenGL and how to do it. I can't remember if I sent something
like this to the list earlier, but even if I have, this overview
contains new info that pertains to Tiger and how it is now easier to
implement thread-safety wherever necessary:
OpenGL inherently is not a thread safe API but there are many cases
where you will want to use multiple threads in order to take
advantage of multi-processor systems (or to work within a given
architecture). The general rule of thumb is that only one thread
should be working on any OpenGL context at a given time. In other
words, there should never be more than one thread accessing a single
context simultaneously. It IS acceptable, however, to have two
threads each accessing DIFFERENT (shared or non-shared) contexts. If
you must access a single OpenGL context from multiple threads, in
order to do that safely one must place a mutex around all OpenGL
calls to it (such as gl* and CGL*).
Modifying objects that are shared between two shared contexts (as
noted above) is thread safe. For instance, if you use one context to
modifies textures in a thread and have a second context in a second
thread which then also modifies some of those same textures, but via
the separate shared context, then the shared object handling between
those two contexts is automatically protected against any thread
errors (you are still following the convention of only talking to a
each context with a single thread at a time).
Something that may not be at first apparent as a thread conflict, but
is, is placing calls to an NSOpenGL context on threads other than the
main NS thread because the main thread within its event loop may need
to talk to the NSOpenGL view for things such as a view resize
(treated like any other NSView) – assuming you are letting the event
loop handle certain attributes of that NSOpenGL view (which happens
by default). To be able to use an NSOpenGLView with OpenGL calls
emanating from a thread other than the main one, it becomes necessary
to use a mutex to deal with this. I'll leave the details of this as
an exercise for the reader ;-)
New in Tiger are a couple new CGL calls, as John Rosasco mentioned
earlier... In order to help with applications that use API such as
NSOpenGL with multithreading Tiger adds API to lock contexts via
CGLLockContext and CGLUnlockContext. If you want to do rendering in
a separate thread from the [NSOpenGL* drawRect:] thread (the main
thread, as I referred to it earlier), you can now lock the context
that you want access to and safely do your OpenGL calls (assuming you
use this locking API around all of your OpenGL calls in all
threads). Of course, these function calls can also be used outside
of NSOpenGL, but do remember that the API is new in 10.4, so if you
must support earlier configurations you will have to rely on normal
mutex thread locking.
Chris Niederauer
OpenGL Software Engineer
Apple Computer, Inc.
Hope this is pretty clear, as I still have yet to catch up on my
sleep this week ;-)
On May 10, 2005, at 7:06 PM, James W. Walker wrote:
John Rosasco <email@hidden> wrote:
Perhaps you're using an NSOpenGLView which is issuing OpenGL calls
behind
the scenes ?
No, this is a Carbon app.
On May 10, 2005, at 5:54 PM, James W. Walker wrote:
The Breakpoints window of the OpenGL Profiler has a checkbox
"Break on thread conflict". What does this mean? If I turn it
on, it breaks on CGLSetParameter, glViewPort, and
CGLUpdateContext every time I set up a context. I am doing all
my OpenGL stuff in the main thread.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
