Was having problems in my main app, so I wrote a simple testbed that does this:
Main thread:
Create context 0
Create context 1
Share context 1 with context 0
Make context 0 current (*)
Begin producer thread
Sleep for a while to give the producer thread a chance to error out
Producer thread:
Make context 1 current
Create a pbuffer
Share pbuffer context with context 0 - wglShareLists() fails
Checking GetLastError() after wglShareLists() failed returns error code 170, whose error string is “The requested resource is in use”. Remove the line (*) above makes everything work okay. I think it is protesting about context 0 being current the main() thread when wglShareLists() is called.
I searched the internet for other people having similar problems, and I found this link, which is exactly the problem that I’ve been having:
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00010855&forum=3dtheory&id=-1
Is this a driver bug, or a ‘feature’ of wgl? I’ve tested it on a FX5600 and Radeon7500 and both give the same result.
Also, one other question… MSDN documentation for wglShareLists() says:
You can only share display lists with rendering contexts within the same process. However, not all rendering contexts in a process can share display lists. Rendering contexts can share display lists only if they use the same implementation of OpenGL functions. All client rendering contexts of a given pixel format can always share display lists.
All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.
Does this mean I shouldn’t share floating point pbuffers with my onscreen rendering context? IIRC, I’ve seen sample code in a lot of places that does this…
Originally posted by Stephen_H:
[b]Was having problems in my main app, so I wrote a simple testbed that does this:
Main thread:
Create context 0
Create context 1
Share context 1 with context 0
Make context 0 current (*)
Begin producer thread
Sleep for a while to give the producer thread a chance to error out
Producer thread:
Make context 1 current
Create a pbuffer
Share pbuffer context with context 0 - wglShareLists() fails
Checking GetLastError() after wglShareLists() failed returns error code 170, whose error string is “The requested resource is in use”. Remove the line (*) above makes everything work okay. I think it is protesting about context 0 being current the main() thread when wglShareLists() is called.
[/b]
That behavior is expected, none of the contexts in the wglShareLists call can be current in a different thread to the one you are calling wglShareLists from. That important piece of information is missing from the MSDN.
Another important rule when using wglMakeCurrent is that you cannot “steal” a context current in a thread from a different thread, i.e., if context A is current in thread 1, and you want to make it current in thread 2, you have to first make it not current in thread 1 and then you can make it current in thread 2.
[b]
Also, one other question… MSDN documentation for wglShareLists() says:
[quote]You can only share display lists with rendering contexts within the same process. However, not all rendering contexts in a process can share display lists. Rendering contexts can share display lists only if they use the same implementation of OpenGL functions. All client rendering contexts of a given pixel format can always share display lists.
All rendering contexts of a shared display list must use an identical pixel format. Otherwise the results depend on the implementation of OpenGL used.
Does this mean I shouldn’t share floating point pbuffers with my onscreen rendering context? IIRC, I’ve seen sample code in a lot of places that does this…[/b][/QUOTE]The tricky wording here is “implementation dependent”. Specially for floating point pbuffers, I would expect ICDs to be flexible in that pixelformat rule (I know only of one graphics card which supports fp frontbuffers). But I’ve read from people in this forum complaints about ICDs being strict in forcing the pixelformat to be the same between the pbuffer and the main context.
Hopefully EXT_render_target should fix this sometime soon…
Thanks for the reply… its really hard to dig up info on wgl issues.
Hopefully EXT_render_target should fix this sometime soon…
I’m doing some really intensive pbuffer stuff at the moment, and I’m hoping and praying for EXT_render_target sometime soon…