PDA

View Full Version : ATI glCompressedTexImage2DARB crash with PBO bound



Brian Lawson
07-03-2007, 11:07 AM
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.

Thanks.

martinsm
07-03-2007, 01:34 PM
Same "Invalid operation" error for me:
http://www.opengl.org/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=3;t=015187

Brian Lawson
07-03-2007, 01:41 PM
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.

ToolTech
10-01-2007, 04:26 PM
Same thing happends to me with BootCamp 1.4 Beta drivers for OSX

Brian Lawson
10-03-2007, 07:21 AM
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.

macarter
10-03-2007, 02:40 PM
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.

Brian Lawson
10-03-2007, 03:31 PM
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?

yooyo
10-04-2007, 03:44 AM
Hmm... If PBO is bound then all following commands use it:

glBitmap
glColorSubTable
glColorTable
glCompressedTexImage1D
glCompressedTexImage2D
glCompressedTexImage3D
glCompressedTexSubImage1D
glCompressedTexSubImage2D
glCompressedTexSubImage3D
glConvolutionFilter1D
glConvolutionFilter2D
glDrawPixels
glPixelMapfv
glPixelMapuiv
glPixelMapusv
glPolygonStipple
glSeparableFilter2D
glTexImage1D
glTexImage2D
glTexImage3D
glTexSubImage1D
glTexSubImage2D
glTexSubImage3DAccording 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.

Brian Lawson
10-04-2007, 04:51 AM
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.

yooyo
10-04-2007, 06:39 AM
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.

Brian Lawson
10-04-2007, 07:41 AM
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".

yooyo
10-04-2007, 09:35 AM
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?