When wglBindTexImageARB is called, a color buffer of a pbuffer is associated with the currently bound texture object. Does wglReleaseTexImageARB expect this same texture object to be bound before the call ?
It doesn’t seem to be mentioned in the spec.
In any case, the new Catalyst 3.1 drivers seem to expect this ( Catalyst 3.0 and GeForces don’t seem to use the currently bound texture object in the wglReleaseTexImageARB call ).
So, is this a bug or should this texture object remain bound ?
Oh, and if anyone from ATI is reading, you might want to look at non-identity texture matrices + bound pbuffers on the 8500. Results are different from what the 9700/GeForce3 produces ( with 3.0, I haven’t tried 3.1 on the 8500 ). Sorry I don’t have time to create a test app right now.
The texture object remains bound but it’s contents are undefined until either you wglBindTexImageARB or glTexImage2D, glCopyTexImage2D any other operation which updates a rectangle of the texture image.
Oh, and yes you need to bind the texture before wglBindTexImageARB().
What is causing problems is code like the following,
// Bind color buffer of a pbuffer to texure id
glBindTexture( GL_TEXTURE_2D, id );
wglBindTexImageARB( hBuffer, WGL_FRONT_LEFT_ARB );
// Bind default texture ( id=0 )
glBindTexture( GL_TEXTURE_2D, 0 );
// This doesn’t work with 3.1 but works with 3.0 and with NVIDIA hardware
wglReleaseTexImageARB( hBuffer, WGL_FRONT_LEFT_ARB );
The 3.1 drivers seems to require the original id before the call to wglReleaseTexImageARB.
As far as I can see, this must be a new driver bug. I don’t see any reason why wglReleaseTexImageARB would need to use the currently bound texture id.
Just to clarify:
When I say “doesn’t work”, I mean the color buffer is not released back to the pbuffer by the wglReleaseTexImageARB call ( if you change the currently bound texture id with glBindTexture ).
I just double checked the spec, and I think what you may be running into is an ambiguity in the spec. From my reading, a pbuffer can potentially be bound to multiple texture objects. (Possibly even in separate contexts) From this reading, I think you do need to say which texture object you are releasing from, and the only way to do that is by having it be current. Allowing ReleaseTexImage to kill all references might cause it to rip a texture out from under another context. The right thing is for the spec to explicitly state how to ref count or disallow multiple binds. I’ll contact the author to try and get it fixed.
Thanks for clearing that up.
Edit: Just re-read your post. I see how this ref counting would be required for such a case. For now, I can just bind the textures before the release call.
[This message has been edited by PH (edited 02-11-2003).]