Another multithreading problems with OpenGL
Author
== short problem desc ==
- Can't display textures that loaded in another thread.
== long problem desc ==
Hello. I've already search the GameDev and found many thread that discussed problems with multithreading with opengl, and most of answer suggest not to use multithreading with opengl. But it seems that I forced to use multithreading, based on my current condition:
- I'm already in halfway through a game developing using OpenGL in Delphi.
- The resource images that my program must preload before the game really is huge and the list keeps growing. That makes the waiting time became so long and long before I finally shown the opening screen. I'm also
- Now I think about moving some of the loading parts into background threads that loading the leftover resources silently, when the foreground thread shows the opening screen.
- The multithread is working nice. I just need to keep track of what texture that hasn't been loaded yet, and when that texture become available to the foreground thread system, I advance the opening screen to used the already loaded texture.
For example: first I loaded the background screen in foreground thread. After that, I show the background screen moving, and I instruct the background thread to load the character face. So while the background screen is displayed, I silently load the character face. When the character's face is loaded completely, I slowly show the character's face to the screen in front of the background. And I instruct the background thread to load another images, and so on and on.
- But the problem arise here. I'm definitely sure that the loading operation is working completely nice, because I'm only moved it and not making any modification, but it seems that *no* texture are being loaded to the openGL memory, even though the texture ID is valid (not zero). When I displayed one of the texture that already loaded by the background thread to the screen, it only shows a white rectangular, just like if the texture never been loaded to the memory. I checked out the texture ID once again, and yet it's still shows a non-zero ID (means that the texture already been loaded successfully into the memory).
- I asked my friend that already has experienced the same sympton, and he said that it's really the limitation of OpenGL - that the OpenGL is not thread-safe. He said that once we leave the current thread which has the "true" OpenGL context, all the OpenGL calling method is not works, such as glBindTexture and such. But the one that keeps me wondering is that the OpenGL function that generates texture ID, the glGenTexture, is working! Why one function working, but another function is not working? I still doesn't understand until now.
- I've read on another topic that the problem is located on the rendering context, that maybe I loaded the texture onto another context.
- But, I've already passed the context that was created in the previous thread (foreground, renderer thread) onto the new thread (background, loader thread). And in the background thread, I used that context to load the texture, by using function such as the glBindTexture and gluBuild2DMipmaps, But still didn't change anything.
But when I see some of the answers in this GameDev, even though it didn't answer my problems directly, I see that maybe there is a workaround solution over this limitation. Is there anyone can helps? Thanks.
Are you calling glXMakeCurrent, aglSetCurrentContext or the Windows equivalent in a thread before you start issuing drawing commands? Also you can try having multiple contexts and sharing data, a good reference on this (if you're on Mac OS X) is this.
Author
Update:
Uhhh, alright... when reading, it seems that the answer is the call to the wglMakeCurrent. But there is still one thing that bothers me. wglMakeCurrent needs hdc, in which hdc means the handle to the device context. Isn't the hdc is only one: the current and the only window's handle that display my game screen? If I need to make a call of wglMakeCurrent in the new thread, which new "handle" I supposed to pass? Is it the old handle? Or I must create a new window and get it's display context? I don't really understand either how was the wglMakeCurrent related to the Multithreading by reading the MSDN documentation about wglMakeCurrent.
Uhhh, alright... when reading, it seems that the answer is the call to the wglMakeCurrent. But there is still one thing that bothers me. wglMakeCurrent needs hdc, in which hdc means the handle to the device context. Isn't the hdc is only one: the current and the only window's handle that display my game screen? If I need to make a call of wglMakeCurrent in the new thread, which new "handle" I supposed to pass? Is it the old handle? Or I must create a new window and get it's display context? I don't really understand either how was the wglMakeCurrent related to the Multithreading by reading the MSDN documentation about wglMakeCurrent.
Author
@Abdulla:
I don't really sure what you mean. Are you talking about wglMakeCurrent (glXMakeCurrent in windows) in the Foreground thread or wglMakeCurrent in Background thread?
If you are talking about wglMakeCurrent in foreground thread, absolutely I've already called that. But if it's in background thread, I haven't yet. Because I think that once the context has been already set, all the gl and glu successive calls will used the current context, regardless which thread calls. Is it true, or not?
I don't really sure what you mean. Are you talking about wglMakeCurrent (glXMakeCurrent in windows) in the Foreground thread or wglMakeCurrent in Background thread?
If you are talking about wglMakeCurrent in foreground thread, absolutely I've already called that. But if it's in background thread, I haven't yet. Because I think that once the context has been already set, all the gl and glu successive calls will used the current context, regardless which thread calls. Is it true, or not?
Author
Another update:
I've read more thoroughly that to use multithread with wglMakeCurrent, I *must* have a rendering context for each thread. But a new rendering context means a new device context, and a new device context means a new window, is it right? I don't really get it...
I've read more thoroughly that to use multithread with wglMakeCurrent, I *must* have a rendering context for each thread. But a new rendering context means a new device context, and a new device context means a new window, is it right? I don't really get it...
The following is written w/o knowledge especially of WGL, so there might be something better out there.
The GL context stores the state of GL. Each thread can have its own GL context, allowing the use of GL also in multi-threaded environments.
Making a GL context current defines its use by the calling thread! AFAIK it should be possible to use the same GL context in several threads but it can be made current for at most one thread at a time. So if you want to "share" the context you have to ensure exclusive use, e.g. by protecting the context with a semaphore. This also requires the owning thread to release the context as soon as possible to make it available to other threads.
On invocations of wglMakeCurrent the device context and the render context need not always be the same. However, there are constraints like that the device context supports GL (of course) and has a matching pixel format.
Normally a context sharing is provided for display lists, textures, and buffer objects, but I don't found such a thing in WGL (what doesn't mean there isn't one).
The GL context stores the state of GL. Each thread can have its own GL context, allowing the use of GL also in multi-threaded environments.
Making a GL context current defines its use by the calling thread! AFAIK it should be possible to use the same GL context in several threads but it can be made current for at most one thread at a time. So if you want to "share" the context you have to ensure exclusive use, e.g. by protecting the context with a semaphore. This also requires the owning thread to release the context as soon as possible to make it available to other threads.
On invocations of wglMakeCurrent the device context and the render context need not always be the same. However, there are constraints like that the device context supports GL (of course) and has a matching pixel format.
Normally a context sharing is provided for display lists, textures, and buffer objects, but I don't found such a thing in WGL (what doesn't mean there isn't one).
As previous posters said: the OpenGL context is only current for one thread at the time.
The most sensible solution to your problem (I think, since I'm using it [wink]) is to load and decode the texture in the resource thread. Then, give the render thread a signal that there is an image waiting to be uploaded to video memory. The render thread can then look at the list of waiting textures and upload them at the start of each frame.
That way you have the CPU and I/O-intensive stuff in a separate thread, and on-screen textures.
The most sensible solution to your problem (I think, since I'm using it [wink]) is to load and decode the texture in the resource thread. Then, give the render thread a signal that there is an image waiting to be uploaded to video memory. The render thread can then look at the list of waiting textures and upload them at the start of each frame.
That way you have the CPU and I/O-intensive stuff in a separate thread, and on-screen textures.
Author
Thanks for your reply! So much mystery is answered. It still has some question left though.
@Haegarr:
- You said that a rendering context can be used by many thread, but only *one* thread can make the rendering context current. Sorry, maybe my knowledge is still low, but isn't that rendering context is made current to the "context device", not to a "specific thread" -- and a thread is not necessarily must own a unique DC, isn't it? So, which device context I must use? Or, if I try to make assumption, I just re-call the wglMakeCurrent to the foreground thread's device context (that way, they used the same device context), but the call must be made within the new thread? -- I mean, it's not about the "device context" itself, it's about what device context I must supplied to the wglMakeCurrent in the new thread?
but I'll try your valuable advice that stated that the previous thread must release the context before the new thread use it. I didn't know that!
@DaBono:
- If I must call wglMakeCurrent for every frame, doesn't it means that the animation will not run smoothly when the signal is set? because what I render in foreground is not merely a "loading animation", but a full game opening.
but your advice is somewhat needs to be considered though... Thanks.
@Haegarr:
- You said that a rendering context can be used by many thread, but only *one* thread can make the rendering context current. Sorry, maybe my knowledge is still low, but isn't that rendering context is made current to the "context device", not to a "specific thread" -- and a thread is not necessarily must own a unique DC, isn't it? So, which device context I must use? Or, if I try to make assumption, I just re-call the wglMakeCurrent to the foreground thread's device context (that way, they used the same device context), but the call must be made within the new thread? -- I mean, it's not about the "device context" itself, it's about what device context I must supplied to the wglMakeCurrent in the new thread?
but I'll try your valuable advice that stated that the previous thread must release the context before the new thread use it. I didn't know that!
@DaBono:
- If I must call wglMakeCurrent for every frame, doesn't it means that the animation will not run smoothly when the signal is set? because what I render in foreground is not merely a "loading animation", but a full game opening.
but your advice is somewhat needs to be considered though... Thanks.
In general, the device context defines where the output will be written to, e.g. which window will show the graphics. The render context is OpenGL's collection of all made textures, display lists, VBOs, and so on. It also stores the current depth comparison function, background clear color, whether or not you've currently invoked a glBegin but not a glEnd yet, and much more of those things. In short: It stores the OpenGL rendering state.
Each thread has the possibility to have at most 1 OpenGL context current. When a thread invokes wglMakeCurrent, it binds the overhanded rendering context to the device context, what means that output generated by using the rendering context has to go to the device context. Moreover, the context is set for the thread from which wglMakeCurrent was called. That means that exactly that thread is now using that rendering context. Until the thread releases the context no other thread is allowed to invoke wglMakeCurrent with just that context.
In fact, wglMakeCurrent binds 3 parts together: The device context, the rendering context, and the invoking thread. The latter dependency is of interest in multi-threaded environments only, and is hence often mentioned with less emphasis.
A thread can deal with multiple device contexts. It is also able to deal with several rendering contexts, but only 1 can be made current at a time. And that rendering context can only be current to 1 thread at a time.
EDIT: I bet that performance will suffer from often rebinding contexts. Since WGL seems to lack support of native context sharing, I think an approach as supposed by DaBono would be best if the desire is just to decouple loading and using of a texture, so at most the texture resource may be needed to be protected by a semaphore.
Each thread has the possibility to have at most 1 OpenGL context current. When a thread invokes wglMakeCurrent, it binds the overhanded rendering context to the device context, what means that output generated by using the rendering context has to go to the device context. Moreover, the context is set for the thread from which wglMakeCurrent was called. That means that exactly that thread is now using that rendering context. Until the thread releases the context no other thread is allowed to invoke wglMakeCurrent with just that context.
In fact, wglMakeCurrent binds 3 parts together: The device context, the rendering context, and the invoking thread. The latter dependency is of interest in multi-threaded environments only, and is hence often mentioned with less emphasis.
A thread can deal with multiple device contexts. It is also able to deal with several rendering contexts, but only 1 can be made current at a time. And that rendering context can only be current to 1 thread at a time.
EDIT: I bet that performance will suffer from often rebinding contexts. Since WGL seems to lack support of native context sharing, I think an approach as supposed by DaBono would be best if the desire is just to decouple loading and using of a texture, so at most the texture resource may be needed to be protected by a semaphore.
Quote:Original post by MightyMartin
@DaBono:
- If I must call wglMakeCurrent for every frame, doesn't it means that the animation will not run smoothly when the signal is set? because what I render in foreground is not merely a "loading animation", but a full game opening.
You don't need to call wglMakeCurrent each frame, but just once. I'll try to make myself a bit clearer. Your resource thread in pseudo-code will do something like:
while( resourcesToLoad ) { FileHandle fp = filesystem.open( textureName ); Image *image = JPGLoader::load(fp); textureQueue.push( image );}createWindow();wglMakeCurrent( hwnd, ... );InitGL();while( gameRunning ) { while( textureQueue.size() > 0 ) glTexImage2D( textureQueue.front(), .... ); renderFrame();}So you see, only one call for wglMakeCurrent is needed.
Unfortunately, the code above is a bit too simple (e.g. you need to do proper locking around the queue), but I think you can get started with this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
