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 9 of 9

Thread: GL_DEPTH_STENCIL_ATTACHMENT vs GL_DEPTH_ATTACHMENT

  1. #1
    Intern Contributor
    Join Date
    Nov 2015
    Posts
    50

    GL_DEPTH_STENCIL_ATTACHMENT vs GL_DEPTH_ATTACHMENT

    Target: OpenGL ES 3.1

    I have a Framebuffer which has a combined DEPTH24_STENCIL8 internal format attachment, which is attached to - to make things interesting - GL_DEPTH_ATTACHMENT (rather than GL_DEPTH_STENCIL_ATTACHMENT as those combined internal formats are normally attached to).

    Now I treat this as a texture, use BindTexture() to upload this to a fragment shader and read it. My tests (on two phones, one with an Adreno GPU and another with Mali) show that in this situation only the first 24 bits of depth get read in the shader.

    If I attach the very same DEPTH24_STENCIL8 thing to GL_DEPTH_STENCIL_ATTACHMENT instead and BindTexture that and read that fr0m the very same fragment shader, then I get both Depth and Stencil.

    The above behaviour suits me very well. The only question is: is this guaranteed by the spec? Especially: is getting only the first 24 bits when we are attached to GL_DEPTH_ATTACHMENT guaranteed? That's what I am most interested at.

    I am reading the OpenGL ES 3.1 spec and I cannot see anything about that...

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,928
    If you bind a depth+stencil texture to GL_DEPTH_ATTACHMENT, only the depth component will be modified by rendering.

    When a depth+stencil texture is bound to a texture unit and read from a shader, you should get either the depth component or the stencil component, depending upon the texture's GL_DEPTH_STENCIL_TEXTURE_MODE parameter. You can't (or shouldn't be able to) read both components from the same shader invocation.

  3. #3
    Intern Contributor
    Join Date
    Nov 2015
    Posts
    50
    Thanks. What if such depth+stencil texture is bound to a texture unit and read, and at the same time attached to a GL_DEPTH_STENCIL_ATTACHMENT attachment point of a Framebuffer (which is not bound for writing to).

    Is this legal? My tests suggest that then reads definitely do not return the depth. I was assuming they return the depth+stencil mixed, but I am not sure.
    If I detach this texture first from the Framebuffer, then I am getting the depths.

    What's interesting, if such texture is bound to a texture unit and read, and at the same time is attached to a GL_DEPTH_ATTACHMENT attachment point of the same unbound Framebufffer, then I do read depths.
    So the fact if I am getting depths or not seems to depend on to which of the 2 possible attachment points this texture is attached (that's the case at least on the 2 devices I mentioned in the first post!).

  4. #4
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,031
    First, there is no `GL_DEPTH_STENCIL_ATTACHMENT`. This enumerator is effectively a bitmask of `GL_DEPTH_ATTACHMENT` and `GL_STENCIL_ATTACHMENT`; attaching to this "attachment" attaches the texture to both.

    Second:

    What if such depth+stencil texture is bound to a texture unit and read, and at the same time attached to a GL_DEPTH_STENCIL_ATTACHMENT attachment point of a Framebuffer (which is not bound for writing to).
    No. This has nothing to do with it having depth or stencil, and everything to do with the fact that it's a feedback loop.

    You cannot read from a texture image that you're writing to, regardless of format.

  5. #5
    Intern Contributor
    Join Date
    Nov 2015
    Posts
    50
    Ok, I know about feedback loops, but the Framebuffer to which the depth+stencil texture is attached to (while being bound as a texture) is not bound anywhere, does that count as a feedback loop?

  6. #6
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,031
    is not bound anywhere
    Are you sure? If the current framebuffer(s) don't have the depth/stencil image attached anywhere, then it shouldn't matter what it is attached as.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,928
    Quote Originally Posted by Utumno View Post
    Ok, I know about feedback loops, but the Framebuffer to which the depth+stencil texture is attached to (while being bound as a texture) is not bound anywhere, does that count as a feedback loop?
    It isn't necessary to unbind the texture from the FBO if the FBO itself is unbound. Also, FBOs bound to the read framebuffer don't matter, only the draw framebuffer.

    Note that in OpenGL 4.5 and later, if you write to a texture in one draw call then read from it in a subsequent draw call you need to call glTextureBarrier() between the two draw calls.

  8. #8
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,031
    Quote Originally Posted by GClements View Post
    Note that in OpenGL 4.5 and later, if you write to a texture in one draw call then read from it in a subsequent draw call you need to call glTextureBarrier() between the two draw calls.
    That's not true. You only need `glTextureBarrier` if you're still rendering to that texture. If you switched FBOs, or changed attachments so that said texture isn't still attached, then the driver is supposed to do whatever work is needed to make the data visible when you switch FBOs or move attachments around.

  9. #9
    Intern Contributor
    Join Date
    Nov 2015
    Posts
    50
    Problem turned out to be completely elsewhere (stencil accidentally overwritten- that's why it appeared to matter if my texture was bound to DEPTH_STENCIL_ATTACHMENT or DEPTH_ATTACHMENT).

    Thank you all for your help though!

Tags for this Thread

Posting Permissions

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