I guess, my statement was unclear: with “sampling a depth texture…previously written to…” I meant “written in a previous draw call”. I’m talking about vanilla shadow mapping here:
- render scene to depthtexture while it is bound as depthbuffer
- render scene 2nd time and sample the depthtexture
That is guaranteed to work, isn’t it?
So long as you have removed the depth texture from the FBO before you do step 2, yes. Otherwise, it is undefined behavior.
The specs are written in prose. Sometimes something is not explictely stated and we need to use common sense to make a meaning of it.
A technical specification describes behavior. This particular part of the spec is very, very clear. It doesn’t rely on anything more than what it says, and there is no need to apply “common sense.” It says what it says, and there’s no wiggle room for interpretation.
If conditions X, Y, and Z happen, undefined behavior results. Full-Stop.
However much it might make “common sense” for something to work a certain way is irrelevant. It is off-spec behavior. Even if every piece of hardware worked as you suggested, it is still, according to The Specification for OpenGL Version 4.1 (and every other version 3.0 or greater), undefined behavior.
If you want to rely on undefined behavior, feel free. But the spec clearly says it is undefined.
Well, then it should be possible to do something like this:
Again, the spec is very clear on this: what matters is what textures are bound to the context and attached to the FBO. Not what the masking state is. And while one would assume that caches are cleared when binding a new FBO, that doesn’t guarantee it. After all, a clever implementation could see that FBO1 and FBO2 use the same depth attachment and therefore not clear the depth cache. As an optimization.
To quote EXT_texture_barrier:
First, there is no EXT_texture_barrier; there is only NV_texture_barrier.
Second, however much you might assume about the functioning of NVIDIA hardware based on NV_texture_barrier’s wording, that doesn’t change what the OpenGL specification says about render targets. Except where NV_texture_barrier changes what it says, of course.
And of course third: even if you assume these things, they will only be true of NVIDIA hardware. So whatever implicit cache invalidation might or might not happen on NVIDIA hardware has no bearing on, for example, ATI hardware.
Obviously the specs need a clarification, since in my eyes, the intended setup never creates a feedback loop.
No, the spec is quite clear. You’re trying to create uncertainty when the spec doesn’t provide any. You think certain hardware works a certain way and that the spec should provide that.
That’s not what specifications are for. It’s possible that masking state could be included in the feedback section. But that is not a “clarification;” that is a change. It now means that IHVs will have to clear depth caches whenever you change the depth mask.
Personally, I don’t see what’s so hard about just unattaching the depth texture or binding a different FBO that doesn’t have that depth texture attached. Not only would this give you in-spec behavior, it wouldn’t make simple glDepthMask() calls cause cache clearing and thus lower performance.