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…

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.

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!).

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.

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?

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.

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.

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.

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!