ATI glCompressedTexImage2DARB crash with PBO bound

I’ve got some code that works fine on various NVidia cards. It’s a DXT texture loading function built on top of pixel buffer objects.

When I try calling glCompressedTexImage2DARB with NULL as the data pointer while the PBO object is also bound – I get an invalid operation error.

Some pseudo code for what I’m trying to do is:

glGenBuffers( 1, &BufferID );
glBufferData( GL_PIXEL_UNPACK_BUFFER_ARB, TotalSize, NULL, UsageFlags );

glGenTextures( 1, &DeviceID );
glBindTexture( GL_TEXTURE_2D, DeviceID );

glCompressedTexImage2DARB( GL_TEXTURE_2D,
                           Width  / (1 << i),
                           Height / (1 << i),
                           NULL ); // NULL here should cause the function to draw texture data from the bound PBO.

Note that I’m also passing in NULL to the glBufferData call so that it simply reserves the memory and does not initialize it.

I would assume that glCompressedTexImage2DARB doesn’t care whether or not the PBO memory has been initialized or not??

Can anyone see anything I might be doing wrong?

Also, if I unbind the PBO before calling glCompressedTexImage2DARB then it works fine.

However, the subsequent call to glCompressedTexSubImage2DARB generates the invalid operation error – which I’m also assuming is probably being generated for the same reasons.


Same “Invalid operation” error for me:;f=3;t=015187

Okay, thanks for that reply. Now I’m starting to feel better about this – in terms of I’m not doing something blatantly silly.

Also, for the record – this is happening on a X1950 with latest drivers.

Same thing happends to me with BootCamp 1.4 Beta drivers for OSX

Well, I submitted a bug report to ATI/AMD right after I made this post. Never got a response. And from the sounds of it – nothing has changed.

For the record, I haven’t gotten back to looking at this issue again as I’ve been busy working on other things.

For now, all of my samples, demos, etc. simply will not run on ATI cards due to this. And I don’t have the time or desire to code around it either.

This may not be a driver bug. Read the spec. NULL does not reserve space for glCompressedTexImage2D, only for glTexImage1D, glTexImage2D, or glTexImage3D. Since you did not populate the PBO with data then it could be argued that an error is the correct response for a function that should always be supplied with valid data.

That’s fine I guess. Can’t argue with that if it is indeed the case.

But the question that then begs to be asked - is why would a driver developer implement them any differently though?? What would be the point in doing so?

Hmm… If PBO is bound then all following commands use it:


According to specification:

void BufferDataARB(enum target, sizeiptrARB size, const void *data, enum usage);

If <data> is non-null, then the source data is copied to the buffer object's data store.  

If <data> is null, then the contents of the buffer object's data store are undefined.

So… Problems could be in ATI internal DXTC decoder because it read garbage from uninitialised PBO and try to interpret as compressed texture. Try to fill PBO with 0.

As soon as I get a chance I will try filling the PBO with 0 and see if that works. Thanks for the tip/suggestion.

Maybe you dont have to fill whole PBO with 0… only first 32 or 64 bytes just to fake decoder to think it is empty buffer. 32 or 64 is wild guess… dont stick on this numbers.

Okay I will keep that in mind. Thanks again.

And while I’m at it – I just want to be clear that everyone who is keeping up with this thread actually understands what the real issue is here.

Of course, being able to provide NULL for the glBufferData call for the bound PBO with the intent of simply “reserving” the memory – is ideal.

The reason this is ideal is that it prevents having to do an unnecessary copy of texture data. Using PBOs allows us to directly load texture data off the disk or from system memory into video memory.

Even having to provide a fake (temporary) buffer of all 0’s would be less than optimal – even though it may serve as a “work around”.

I understand what you want.

If PBO is bound then any glTextureXD call interpret NULL as OFFSET in PBO, so it will not reserve memory for texture… it will copy data from currently bound PBO.

If PBO is not bound then glTextureXD will allocate memory for texture.

One more thing… try to create system memory buffer and fill it with random numbers. Then create & upload compressed texture from that buffer. Im wondering will it crash again?