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 );
glBindBuffer( GL_PIXEL_UNPACK_BUFFER_ARB, BufferID );
glBufferData( GL_PIXEL_UNPACK_BUFFER_ARB, TotalSize, NULL, UsageFlags );
glGenTextures( 1, &DeviceID );
glBindTexture( GL_TEXTURE_2D, DeviceID );
glCompressedTexImage2DARB( GL_TEXTURE_2D,
i,
Format,
Width / (1 << i),
Height / (1 << i),
0,
MipMapSize,
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.
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?
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.
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.
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”.
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?