Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime
P.S. Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I don't know if there are applications that draw opengl in multiple threads in different contents, and if current code would make any problems with these.
Leon
On Mon, Mar 20, 2006 at 05:37:50PM +0100, Leon Freitag wrote:
Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I don't know if there are applications that draw opengl in multiple threads in different contents, and if current code would make any problems with these.
Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context.
So instead of retrieving the context on each ENTER_GL / LEAVE_GL macro using the GLX call, one can simply store the currently bound context for the current thread in a thread-local variable.
This is what Mike's patch does.
Lionel
Am Montag, 20. März 2006 23:26 schrieb Lionel Ulmer:
Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context.
What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads.
A little bit OT, but related to multi-threaded opengl is a bug in the dri radeon driver(https://bugs.freedesktop.org/show_bug.cgi?id=6240). I've reported it to the dri devs but didn't get any response so far.
Stefan
Hi Stefan,
On Tuesday 21 March 2006 01:41, Stefan Dösinger wrote:
Am Montag, 20. März 2006 23:26 schrieb Lionel Ulmer:
Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context.
What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads.
You're right you can use the same context for many threads. you only have to "map" it to each threads (using MakeCurrent APIs) Anyway i have seen many problems when using the same context active for too many threads (seems the nvidia drivers don't like this kind of behavior)
A little bit OT, but related to multi-threaded opengl is a bug in the dri radeon driver(https://bugs.freedesktop.org/show_bug.cgi?id=6240). I've reported it to the dri devs but didn't get any response so far.
:)
Stefan
Regards, Raphael
What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads.
man glXMakeCurrent
BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called. Seems pretty clear to me, but well, my man pages may be outdated :-)
Lionel
Am Dienstag, 21. März 2006 23:31 schrieb Lionel Ulmer:
What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads.
man glXMakeCurrent
BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called.Seems pretty clear to me, but well, my man pages may be outdated :-)
Indeed. I must have overloocked it :-|
Thanks for the clarification
-
Leon Freitag -
Lionel Ulmer -
Raphael -
Stefan Dösinger