Our findings seem to indicate that it doesn’t, neither on NVidia nor AMD implementations (unless there was something wrong with our tests, which I can’t completely rule out).
If the answer is that depth is written regardless of glDepthMask state, is the recommended way to prevent such depth writing to temporarily unbind the depth render target?
The renderbuffer object does respect the state of glDepthMask, or that is its the framebuffer object that respect the depth mask though thats semantics I guess.
If you could supply a tiny snippet showing how your tests indicates that this isnt true it might be easier to pin point your errors
AFAIK, fbo are the same thing as the default framebuffer provided by the window system. Like this last one, they have their own states so IMO, the depth writing state is framebuffer dependant and may varies depending on the bound framebuffer name. I think it must be somewhere in the spec.
As said above FBOs do have their own states. That means you need to first bind the FBO, then set the states, such as depth-mask, color-mask, etc. and then perform the operations that should be masked. If you first set the masks and then bind the FBO, it will actually be applied to the wrong buffer and not work as expected.
Nope.
You should be able to set any state that you want, even before binding a FBO. glDepthMask, glEnable, glBlendFunc and all the other states. These are suppose to be GPU states.
My mistake, V-man is right. But I can’t understand why depth masking is not fbo dependant.
Ilian, I can’t find something about depth masking in per fbo states.
Furthermore the gl spec is not very explicit about that and I understood the contrary reading “4.2 Whole framebuffer operations” Because I expected to find in this section operations that affect the whole fbo (as the title says) and not operations that affects also all created framebuffers (window system and application ones).
