Hello List
I get at crash when running my SDL/OpenGL app threaded on Intel OS X.
The crash happens in glIsBufferARB which is called from the spawned thread.
This code is wrapped in mutex’s so no other threads should be accessing the
buffer.
The crash doesn’t happen if I run the app single threaded.
Also the app runs fine threaded as long as I don’t create VBOs in the
spawned thread.
Any Ideas?
/Jacob Kolding
Le 27 avr. 07 ? 21:24, Jacob Ole Juul Kolding a ?crit :
This code is wrapped in mutex’s so no other threads should be
accessing the buffer.
Are you sure that a single thread accesses your OpenGL context ?
OpenGL contexts are not thread-safe on osx, your mutex should wrap
access to the context.
See the guidelines here [1] for more info.
Best,
Daniel
[1] http://developer.apple.com/documentation/GraphicsImaging/
Conceptual/OpenGL-MacProgGuide/opengl_threading/
chapter_12_section_1.html#//apple_ref/doc/uid/TP40001987-CH409-SW1
Le 27 avr. 07 ? 21:24, Jacob Ole Juul Kolding a ?crit :
This code is wrapped in mutex’s so no other threads should be
accessing the buffer.Are you sure that a single thread accesses your OpenGL context ?
OpenGL contexts are not thread-safe on osx, your mutex should wrap
access to the context.
As far as I can tell both my threads lock the mutex before accessing OpenGL
data, but maybe I over looked something,
or SDL/OS X has some control thread that I don’t know of?
/Jacob Kolding
See the guidelines here [1] for more info.On 4/27/07, Daniel B?nzli <daniel.buenzli at epfl.ch> wrote:
Best,
Daniel
[1] http://developer.apple.com/documentation/GraphicsImaging/
Conceptual/OpenGL-MacProgGuide/opengl_threading/
chapter_12_section_1.html#//apple_ref/doc/uid/TP40001987-CH409-SW1
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Le 27 avr. 07 ? 21:24, Jacob Ole Juul Kolding a ?crit :
This code is wrapped in mutex’s so no other threads should be
accessing the buffer.Are you sure that a single thread accesses your OpenGL context ?
OpenGL contexts are not thread-safe on osx, your mutex should wrap
access to the context.As far as I can tell both my threads lock the mutex before accessing
OpenGL data, but maybe I over looked something,
or SDL/OS X has some control thread that I don’t know of?/Jacob Kolding
See the guidelines here [1] for more info.
Well… If I move all OpenGL calls to one thread it runs.
/Jacob Kolding
Best,On 4/27/07, Jacob Ole Juul Kolding <@Jacob_Kolding> wrote:
On 4/27/07, Daniel B?nzli <daniel.buenzli at epfl.ch> wrote:
Daniel
[1] http://developer.apple.com/documentation/GraphicsImaging/
Conceptual/OpenGL-MacProgGuide/opengl_threading/
chapter_12_section_1.html#//apple_ref/doc/uid/TP40001987-CH409-SW1
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Le 27 avr. 07 ? 23:36, Jacob Ole Juul Kolding a ?crit :
Well… If I move all OpenGL calls to one thread it runs.
That’s the point. I forgot to say, if you are on SDL 1.2 there is a
single OpenGL context at a given time (IIRC). Hence concretly it
means no concurrent calls to gl* functions.
Best,
Daniel
Le 27 avr. 07 ? 23:36, Jacob Ole Juul Kolding a ?crit :
Well… If I move all OpenGL calls to one thread it runs.
That’s the point. I forgot to say, if you are on SDL 1.2 there is a
single OpenGL context at a given time (IIRC). Hence concretly it
means no concurrent calls to gl* functions.
Just to make sure I understand, If my mutex code worked correctly, then I
could have gl calls in both threads?
/Jacob Kolding
Best,On 4/27/07, Daniel B?nzli <daniel.buenzli at epfl.ch> wrote:
Daniel
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Just to make sure I understand, If my mutex code worked correctly, then I
could have gl calls in both threads?
If I remember correctly, the GL context is thread specific. I’m not sure
whether you can share the same context in many threads, or if you’ll need
to create a new context for that thread. All of this is platform specific,
too.
// MartinOn Sat, 28 Apr 2007, Jacob Ole Juul Kolding wrote:
Just to make sure I understand, If my mutex code worked correctly, then
I
could have gl calls in both threads?If I remember correctly, the GL context is thread specific. I’m not sure
whether you can share the same context in many threads, or if you’ll need
to create a new context for that thread. All of this is platform specific,
too.
Ok, thanks. I’ll just put all gl calls in one thread to be sure…
// MartinOn 4/28/07, Martin Storsj? wrote:
On Sat, 28 Apr 2007, Jacob Ole Juul Kolding wrote:
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Le 28 avr. 07 ? 00:49, Martin Storsj? a ?crit :
If I remember correctly, the GL context is thread specific. I’m not
sure
whether you can share the same context in many threads, or if
you’ll need
to create a new context for that thread. All of this is platform
specific,
too.
No, I don’t think it is a problem, there’s no gl magic in a thread.
Just make sure your threads acquire a lock before calling any
(section of) gl* commands to mutually exclude them from accessing the
OpenGL engine.
Note however that depending on the structure of your code this may
actually decrease performance, each thread always waiting on the
other. Designating a thread for gl commands is certainly a simpler
and cleaner solution.
Best,
Daniel
I am quite sure that it IS a requirement in SDL-1.2 that only one thread
ever access the video system. This is a platform dependent requirement
(some platforms can tolerate code disobeying this requirement, some can
not), so you may not have noticed it, depending on what platforms you
work with. However, to be sure SDL will work everywhere it is supposed
to, only one thread (the one that initializes SDL, generally the initial
thread) can ever access video.On Sat, Apr 28, 2007 at 10:22:22AM +0200, Daniel B?nzli wrote:
Le 28 avr. 07 ? 00:49, Martin Storsj? a ?crit :
If I remember correctly, the GL context is thread specific. I’m not
sure whether you can share the same context in many threads, or if
you’ll need to create a new context for that thread. All of this is
platform specific, too.No, I don’t think it is a problem, there’s no gl magic in a thread.
Just make sure your threads acquire a lock before calling any (section
of) gl* commands to mutually exclude them from accessing the OpenGL
engine.
–
Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070428/97fffa45/attachment.pgp
Le 28 avr. 07 ? 13:48, Steaphan Greene a ?crit :
I am quite sure that it IS a requirement in SDL-1.2 that only one
thread
ever access the video system.
Note we are talking about two different things here. When you use
OpenGL you are not using SDL’s video system anymore.
Now it still may be that some platforms disallow two threads to enter
OpenGL even if they don’t do it concurrently. I know at least that
it’s not the case on osx. But I’am interested in knowing for the
other platforms. Can anybody provide more information ?
Best,
Daniel
No, I was referring to the use of OpenGL. Only the thread which
initializes SDL can make OpenGL calls. I ran into this on an project a
few years ago where I disobeyed this. If I remember right, it ran fine
in Linux, but crashed on Windows - until I adjusted the code to only use
the main thread for opengl access.On Sat, Apr 28, 2007 at 02:17:44PM +0200, Daniel B?nzli wrote:
Le 28 avr. 07 ? 13:48, Steaphan Greene a ?crit :
I am quite sure that it IS a requirement in SDL-1.2 that only one
thread ever access the video system.Note we are talking about two different things here. When you use
OpenGL you are not using SDL’s video system anymore.Now it still may be that some platforms disallow two threads to enter
OpenGL even if they don’t do it concurrently. I know at least that
it’s not the case on osx. But I’am interested in knowing for the other
platforms. Can anybody provide more information ?
–
Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070428/15872d6c/attachment.pgp
Now it still may be that some platforms disallow two threads to enter
OpenGL even if they don’t do it concurrently. I know at least that
it’s not the case on osx. But I’am interested in knowing for the
other platforms. Can anybody provide more information ?
OS X at least doesn’t disallow two threads using OpenGL at the same time,
but you might need to do some additional handling of the GL context.
At least this is what the manual on OS X for CGLSetCurrentContext says:
Discussion
There can be only one current rendering context. Subsequent OpenGL
rendering calls operate on the current rendering context to modify the
drawable object associated with it.You can use AGL macros to bypass the current rendering context mechanism
and maintain your own current rendering context.A context is current on a per-thread basis. Multiple threads must
serialize calls into the same context.
I’m not sure what the current context is set to in new threads. Perhaps
something like this would work:
// Main thread, before starting new threads
CGLContextObj context = CGLGetCurrentContext();
…
// Child thread, immediately after being started
CGLSetCurrentContext(context);
In that case, everything should work fine as long as all calls are
correctly serialized.
But as other also have mentioned, this behaviour is very platform
dependant; I recall having had problems on Windows. If possible, the
cleanest solution is to use the main thread for all video, of course.
// MartinOn Sat, 28 Apr 2007, Daniel B?nzli wrote: