PDA

View Full Version : threads & pbuffers



Stephen_H
06-21-2004, 11:51 AM
I've been fooling around with a problem on and off for the past few days.

What I want to do is create a pbuffer on one thread (with its own context), and then later delete it on another thread (with its own context). I tried doing this in my main application, but eventually i get an "out of memory" error from OpenGL after I'd created & destroyed a number of pbuffers.

So what I've done is written a testbed that creates a pbuffer on one thread (with its own context) and passes it to another thread (with its own context) that frees it:

thread 1:
create pbuffer
put ptr to it in a global variable
wake up thread 2
wait for thread 2

thread 2:
wait for thread 1
get the global variable
delete the pbuffer
wake thread 1
wait for thread 1

Eventually (after creating & destroying 67 floating point NV_RECTANLGE pbuffers) wglCreatePbufferARB always fails. There seems to be a pbuffer leak or something. GetLastError() returns 1813 which is Window's error ERROR_RESOURCE_TYPE_NOT_FOUND. That error isn't even listed on the pbuffer spec as a wglCreatePbufferARB error.

Furthermore, in thread2, I'm testing the return values of wglDeleteContext, wglReleasePbufferDCARB, and wglDestroyPbufferARB and none of them are failing... so the pbuffers seem to be silently being leaked...

I also tried having the threads share RCs, but it didn't make any difference.

I couldn't find anything in the pbuffer extension docs about sharing pbuffers between threads, so I thought this would work... am I missing something?

Stephen_H
06-21-2004, 12:09 PM
From MSDN:


The OpenGL library supports multiple implementations of its functions. Extension functions supported in one rendering context are not necessarily available in a separate rendering context. Thus, for a given rendering context in an application, use the function addresses returned by the wglGetProcAddress function only.wgl functions can be context specific... which might explain why deleting the pbuffer on a different GL context than it was allocated wouldn't work. But the deletion functions should still return errors!?!

But in my testbed, it was still failing even when I shared the same context between threads...

Edit - the wgl functions have the same proc address on both GL contexts, I just checked all the wgl functions

plasmonster
06-21-2004, 07:10 PM
Recently, I came across this pearl from MSDN :p


It is an error for a thread to delete a rendering context that is another thread's current rendering context. However, if a rendering context is the calling thread's current rendering context, wglDeleteContext flushes all OpenGL drawing commands and makes the rendering context not current before deleting it. In this case, relying on wglDeleteContext to make a rendering context not current requires the programmer to delete or release the associated device context.You can eye-ball the rest here, if you haven't already.

http://msdn.microsoft.com/library/en-us/opengl/ntopnglo_4eb7.asp?frame=true

It sounds like thread sync problems, but I'm not sure. This wording suggests that what you're attempting should be possible, provided the driver cooperates.

edit:

fixed URL.

Stephen_H
06-22-2004, 12:12 PM
Thanks Q! I'll take a look into it when I get a chance.