What I’m seeing is that glStencilMask affects glBlitFramebuffer( GL_STENCIL_BUFFER_BIT ). Set it to 0 and nothing gets copied. Set it to ~0 and it all gets copied.
I’d say that glClear is slightly over specified here.
Blit is affected by per-fragment operations (some) and masking takes place after them. I cant see any reason (in spec) why it would be exempted from masking.
The question is though, is this specified in the spec, or is this “implementation-dependent” behavior?
For instance, if it’s like glDepthMask, glStencilMask doesn’t matter a hill of beans for the normal pipeline unless GL_STENCIL_TEST is enabled. That is unless tests are enabled, you can’t write stencil (similar to glDepthMask/GL_DEPTH_TEST; link)
glClear is a notable exception. It doesn’t care about DEPTH_TEST or STENCIL_TEST. It bypasses those and goes straight to using the masks, which is odd.
With these precedents, it’s not clear whether glBlitFramebuffer should honor the masks or not, and if so, whether it should require the TEST enables to be set as well.
My interpretation is that depth test and stencil test are per-fragment operations, and all but the few of these are bypassed by both Clear and Blit (this is mentioned explicitly, and note that Clear doesn’t mention depth test state either).
Masking is further stages (as outlined by spec) and there isnt any indication that either of the function have some special treatment on that stages (in fact this additional disambiguation for Clear causes confusion).
Note that even for normal operations masks ‘work’ always (at least on logical level) - not enabling depth/stencil test prevents writing the data before masks have even chance to act.
It could be specified better, but from current language I think this is the correct interpretation.
I also don’t think there is possibility for ‘implementation dependent’ behaviour here - spec is usually very clear when this is the case.
Ok. I think we both agree that the spec language is a little misleading here.
For glClear I see:
but regarding glBlitFramebuffer…:
Note the conspicuous absense here of “The masking operations described in section 4.2.2 are also applied.”
Masking is further stages (as outlined by spec) and there isnt any indication that either of the function have some special treatment on that stages (in fact this additional disambiguation for Clear causes confusion).
Agreed. That certainly is one possibility, but as I think we both admit, it isn’t crystal clear from the spec’s language.
The assumption being that buffer write masking “always” happens no matter what when writing a value through a framebuffer in any way (Clear, Blit, CopyPixels, render, etc.). And Clear’s qualification about write masks being superfluous given 4.2.2.