GL_RG32F vs GL_RGB32F in ATI's cards

On Nvidia cards, all works as expected but for some reason when I run the program on Ati FirePro 4900 nothing is visible (All is transparent).
After a couple of hours, I had discovered that if I use a GL_RGB32F instead a GL_RG32F it works with ATI too.

I tried with GL_RG too but it doesn't change the result (all transparent). Dual depth peeling or a least my implementation require 2 textures for depth information, one for read, one for write. I could use two regular textures or a texture array but for simplicity (maybe a bit lazy too) I used a 3D texture. By the way, for the MSAA version I am using a GL_TEXTURE_2D_MULTISAMPLE_ARRAY and GL_RG32F works fine (more or less) so maybe ATI doesn't like 3D textures.

Confirmed, I have changed my 3D texture by a GL_TEXTURE_2D_ARRAY and it works. I don't know if it is a ATI's driver problem or that I don't understand the different between GL_TEXTURE_2D_ARRAY and GL_TEXTURE_3D.

It's likely allowing you to render to one layer of a 2D texture array and read from another layer, but the same doesn't hold true for a 3D texture. This is probably due to implementation-specific details on how those textures are laid out.

Confirmed, I have changed my 3D texture by a GL_TEXTURE_2D_ARRAY and it works. I don't know if it is a ATI's driver problem or that I don't understand the different between GL_TEXTURE_2D_ARRAY and GL_TEXTURE_3D.

The main difference is that a 2D array texture doesn't perform interpolation or mipmapping in the third dimension, and the third texture coordinate (r) is always clamped regardless of the repeat mode.

According to §9.3 (Feedback Loops Between Textures and the Framebuffer) of the 4.3 core profile specification, the behaviour is undefined if it's possible for the bound program to sample from a part of a texture which is attached to the bound framebuffer.

If you're attaching one layer of a 3D texture or 2D array texture to the bound framebuffer, and the shader is reading from the same texture, and the only thing stopping it reading from the "write" layer is that the shader logic (and/or the values of uniforms and attributes) ensures that it doesn't pass the wrong value as the third texture coordinate, then the behaviour is undefined. Maybe it will work, maybe it won't, maybe it will vary depending upon any number of factors.