Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 5 of 5

Thread: GL_RG32F vs GL_RGB32F in ATI's cards

Hybrid View

  1. #1
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    15

    GL_RG32F vs GL_RGB32F in ATI's cards

    Hi All,

    I am implementing a Order Independent transparency with Dual peeling based on http://developer.download.nvidia.com...pthPeeling.pdf.

    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.

    Somebody has any idea of what is happens?

    This is how I am creating the texture.

    Code :
            glGenTextures(1, &m_ID);
            glBindTexture(GL_TEXTURE_3D, m_ID);
            glTexImage3D(GL_TEXTURE_3D, 0, GL_RG32F, m_Width, m_Height, m_Depth, m_Border, GL_RGB, GL_FLOAT, NULL);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); 
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_S, GL_CLAMP);
            glTexParameteri(GL_TEXTURE_3D, GL_TEXTURE_WRAP_T, GL_CLAMP);

    Thanks in advance,

    Carlos.

    http://developer.download.nvidia.com...pthPeeling.pdf

  2. #2
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    318
    Your code snippet has GL_RG32F matched with GL_RGB, which is likely the issue. Use GL_RG instead.

    Also, why a 3D texture? I haven't implemented dual-depth peeling before, though I have done a regular depth peeling algorithm, and I'm not sure why you'd need a 3D texture over a 2D texture.

  3. #3
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    15
    Hi Malexander,

    Thanks for the reply.

    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.

    Thanks again Malexander,

    Carlos.
    Last edited by icebeat; 07-16-2013 at 05:59 AM. Reason: Added confirmation.

  4. #4
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    318
    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.

  5. #5
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    490
    Quote Originally Posted by icebeat View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •