pbuffers, glTexSubImage2D and ATI...

Hi,

I have an app which uses pbuffers for render to texture. However, at certain times I would like to load an existing image into the pbuffer. The following code snippet:

m_pPBuffer->Bind();
glTexSubImage2D(
GL_TEXTURE_2D,
0,
0, 0,
pImg->GetWidth(), pImg->GetHeight(),
GL_BGRA_EXT,
GL_UNSIGNED_BYTE,
pImg->GetData()
);
m_pPBuffer->Release();

works fine on an NVIDIA GeForce4 Ti4200. However, it crashes on an ATI Radeon9600 Pro.

I have also tried a test code on the ATI card which replaces a single texel:

unsigned char rgcTest = { 0, 0, 0, 255 };
m_pPBuffer->Bind();
glTexSubImage2D(
GL_TEXTURE_2D,
0,
0, 0,
1, 1,
GL_RGBA,
GL_UNSIGNED_BYTE,
rgcTest
);
m_pPBuffer->Release();

which also crashes on the ATI card.
All other pbuffer functions (rendering to it, binding it to a texture, etc) work fine on both NVIDIA and ATI cards.
Latest drivers used for both.
No errors reported by glGetError().

Does anyone have any idea why it’s crashing?

I’m not completely sure what you want to do here. Do you just want to change one pixel in your render-to-texture pbuffer? In that case, bind it as a context and draw into it (e.g. glDrawPixels).

When you bind a RTT PBuffer as a texture, subsequent calls to TexImage releases the PBuffer and replaces it with a new texture.
TexSubImage shouldn’t work because you don’t actually have any texture data allocated.

-Won

What drivers?

No, I’m changing more than one pixel. In fact, I’m drawing geometry into the pbuffer and later using it as a texture.

Texture data should already have been allocated by the pbuffer initialization calls (wglCreatePBufferARB). Other pbuffer functions (rendering geometry into it, binding it as a texture) work fine on both NVIDIA and ATI, but TexSubImage2D only works on the NVIDIA card.

V-man:
Tested on NVIDIA Det 45.23 as well as ForceWare 53.03.
ATI Drivers are Catalyst 3.9.

Just a suggestion, when you setup your pBuffer, are you specifying the required RTT settings (iAttribs from memory)? A bug was identified recently in another thread (on NV hardware). Perhaps there’s an ATI version of this bug? (ie. Make sure you are only specifying the required Attribs for your pBuffer)

Dak –

The single pixel part doesn’t matter. My point is: To put an image in your PBuffer do not use TexImage calls. They don’t do the right thing. You have to draw into the pbuffer, with DrawPixels or any other rendering method. The behavior between TexImage in this case is covered in the Render-To-Texture spec.

Since your pbuffer is current (my guess is your using ATI’s PBuffer class? it’s got some issues), the TexSubImage calls are trying to access a texture for rendering into the pbuffer which doesn’t exist unless you have already allocated one.

Even if your pbuffer is bound as a texture, calls to the TexImage-style calls will relase the pbuffer as texture and try to make a new texture.

-Won

rgpc: Did you mean this thread?. I’ve gone through the pbuffer attrib bits, doesn’t seem to be the problem. I think the other thread focused more on CopyTexSubImage, i.e. pbuffer -> some other texture. Was a good suggestion though.

Won: Taken from the RTT spec, under Issues:
"10. Should there be any restrictions on the texture operations that can be performed on a color buffer?

Yes. We allow TexSubImage and CopyTexSubImage calls but disallow TexImage and CopyTexImage calls."

Which is why I’m using TexSubImage, not TexImage.

I’m using a modified version of NVIDIA’s PBuffer class, I have looked through ATI’s version, and besides the hardcoded attribs in ATI’s case, there are no major differences.

I would have thought that wglCreatePbufferARB allocates the memory for the pbuffer and texture (which on new drivers should be the same). After all, wglQueryPbufferARB does return the dimensions requested for in wglCreatePbufferARB.

CopyTexImage and TexImage should not be used to modify the contents of a pbuffer. You need to read the WGL_ARB_render_texture spec. If you want to change the contents of the pbuffer, use DrawPixels. That’s what it’s for, afterall.

idr: Sorry if you missed my reply post above:

Won: Taken from the RTT spec, under Issues:
"10. Should there be any restrictions on the texture operations that can be performed on a color buffer?

Yes. We allow TexSubImage and CopyTexSubImage calls but disallow TexImage and CopyTexImage calls."

Which is why I’m using TexSubImage, not TexImage.

sorry to bring this old topic back, but I have the same problem at the moment. The driver crashes at a glTexSubImage2D. As I understood the spec it should be possible to access the bound color pbuffer via glTexSubImage2D.

Is this a driver bug, has anyone else tried it out?

And what about GetTexImage calls? Are they supposed to work with pbuffers?

using: Catalyst 5.2 on a Radeon 9800