PBO/textures on ATI

[pjcozzi]

Hi,

I have some PBO/texture code that works on NVIDIA but not ATI. On NVIDIA, the scene looks like:

http://miniglobe.sourceforge.net/ATI/Correct.png

On ATI, it looks like the alignment is off:

http://miniglobe.sourceforge.net/ATI/Incorrect.png

This is using a 5400x2700 RGB texture. If I resize the texture to 2700x1350 or add an alpha component, it works on ATI. Perhaps this is related to a bug we discussed a while back: ATI: glTexImage2D with large texture doesn't work (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=49106&Number=2523 68).

Here is the code for each texture:

5400x2700 RGB (works on NVIDIA, artifacts on ATI)


glGenBuffers(1,&buffer);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glBufferData(GL_PIXEL_UNPACK_BUFFER_ARB,43740000,0 ,GL_STREAM_DRAW);
glBufferSubData(GL_PIXEL_UNPACK_BUFFER_ARB,0,43740 000,data);

glGenTextures(1,&texture);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,0);
glBindTexture(GL_TEXTURE_2D,texture);
glTexImage2D(GL_TEXTURE_2D,0,GL_RGB8,5400,2700,0,G L_RGB,GL_UNSIGNED_BYTE,0);

glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glPixelStorei(GL_UNPACK_ALIGNMENT,4);
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,5400,2700,GL_B GR,GL_UNSIGNED_BYTE,0);
glDeleteBuffers(1,&buffer);

2700x1350 RGB (works on both NVIDIA and ATI)


glGenBuffers(1,&buffer);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glBufferData(GL_PIXEL_UNPACK_BUFFER_ARB,10935000,0 ,GL_STREAM_DRAW);
glBufferSubData(GL_PIXEL_UNPACK_BUFFER_ARB,0,10935 000,data);

glGenTextures(1,&texture);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,0);
glBindTexture(GL_TEXTURE_2D,texture);
glTexImage2D(GL_TEXTURE_2D,0,GL_RGB8,2700,1350,0,G L_RGB,GL_UNSIGNED_BYTE,0);

glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glPixelStorei(GL_UNPACK_ALIGNMENT,4);
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,2700,1350,GL_B GR,GL_UNSIGNED_BYTE,0);
glDeleteBuffers(1,&buffer);

5400x2700 RGBA (works on both NVIDIA and ATI)


glGenBuffers(1,&buffer);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glBufferData(GL_PIXEL_UNPACK_BUFFER_ARB,58320000,0 ,GL_STREAM_DRAW);
glBufferSubData(GL_PIXEL_UNPACK_BUFFER_ARB,0,58320 000,data);

glGenTextures(1,&texture);
glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,0);
glBindTexture(GL_TEXTURE_2D,texture);
glTexImage2D(GL_TEXTURE_2D,0,GL_RGB8,5400,2700,0,G L_RGB,GL_UNSIGNED_BYTE,0);

glBindBuffer(GL_PIXEL_UNPACK_BUFFER_ARB,buffer);
glPixelStorei(GL_UNPACK_ALIGNMENT,4);
glTexSubImage2D(GL_TEXTURE_2D,0,0,0,5400,2700,GL_B GRA,GL_UNSIGNED_BYTE,0);
glDeleteBuffers(1,&buffer);

Here are the textures:
5400x2700 RGB: world.topo.200412.3x5400x2700.jpg (http://miniglobe.sourceforge.net/ATI/world.topo.200412.3x5400x2700.jpg) 2700x1350 RGB: world.topo.200412.3x2700x1350.jpg (http://miniglobe.sourceforge.net/ATI/world.topo.200412.3x2700x1350.jpg) 5400x2700 RGBA: world.topo.200412.4x5400x2700.png (http://miniglobe.sourceforge.net/ATI/world.topo.200412.4x5400x2700.png) Original source: NASA Visible Earth (http://visibleearth.nasa.gov/view_rec.php?id=7135)
I thought this could have something to do with my call to glPixelStorei, but I verified the data is indeed 4 byte aligned.

I tested using a Radeon HD 5870 with Catalyst 10.11 on Vista 64.

Thanks,
Patrick

[skynet]

I experience the same problem on ATI FireGL V5200 (8.593 Drivers, quite old). Uploading an RGB texture as 1024x1024 works, going above results in garbage (as if the unpack alignment is not right, but I DO set the alignment correctly to 1 before uploading te image). I do not use PBOs, though.

[Pierre Boudier]

we just fixed an issue with texture uploads when size>2^23, this is not available in a public driver yet, but should address the issue for recent hardware.
this will not do anything for ATI FireGL V5200 though. have you tried using a more recent driver ?

[pjcozzi]

we just fixed an issue with texture uploads when size>2^23, this is not available in a public driver yet, but should address the issue for recent hardware.
I will retest when this driver is available. Thanks.

I assume you mean 2^23 bytes. It looks like it is not a problem with all textures greater than this size because all my textures are larger than 2^23, and two out of three of them work.

Regards,
Patrick

[Pierre Boudier]

yes, the issue is not for all texture formats :)

Pierre B.

[pjcozzi]

we just fixed an issue with texture uploads when size>2^23, this is not available in a public driver yet, but should address the issue for recent hardware.
this will not do anything for ATI FireGL V5200 though. have you tried using a more recent driver ?
I just tried Catalyst 10.12 and still experience the issue.

Thanks,
Patrick

[aqnuep]

I would suggest you to use multiple TexSubImage calls so that you could stay under the implementation limitation on the amount of bytes possible to be transferred. I know it is just a workaround but it should be good until the issue is not solved.

[mhagain]

What happens if you try GL_BGRA?

[aqnuep]

mhagain is in fact right. As I've seen BGRA worked on both cards, and is the best choice performance-wise, even though it could consume more memory and bandwidth, it is a native format and TexSubImage would perform better with that (no need for internal repack otherwise needed as 8-bit three-component formats are always promoted to BGRX anyway).

[Dark Photon]

mhagain is in fact right. As I've seen BGRA worked on both cards, and is the best choice performance-wise, even though it could consume more memory and bandwidth, it is a native format and TexSubImage would perform better with that (no need for internal repack otherwise needed as 8-bit three-component formats are always promoted to BGRX anyway).
In terms of "best choice performance-wise", consider DXT1. Unless the driver is buggy, this is a much, [B]much better choice for performance and memory consumption:
BGRA8/RGBA8 - 32 bits/texel
BGR8/RGB8 - 24 bits/texel
DXT1 - 4 bits/texelFor many apps, DXT1 quality is fine, and it is a lot better than the avg number of bits/texel suggests!

Though if you do need better brightness/color quality but still don't want to eat the huge mem/bandwidth consumption of RGB8/BGR8, consider YCoCg encoded into DXT5 textures (8 bits/texel).

[mhagain]

It really depends on the driver. I've seen drivers that seem to pull an entire texture back to system RAM in order to do a glTexSubImage update unless you specify format and type exactly the way they like it. You obviously don't want that to be happening if you're doing it at runtime.

It's definitely worth benching the various formats and seeing which works best for you though, both in terms of correctness and performance (and beware that it may turn out to be a case of "pick one"...)

[aqnuep]

In terms of "best choice performance-wise", consider DXT1
Sorry, I didn't even consider compressed formats in this case but good point.