glBlitFramebuffer & buffer write masks

[Dark Photon]

Are buffer writemasks supposed to affect glBlitFramebuffer (i.e. glColorMask, glDepthMask, glStencilMask)?

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.

This surprised me because neither the man page, the spec, nor the original extension state that glBlitFramebuffer honors the buffer write masks (AFAICS). Whereas (by contrast) glClear is very clear about that.

So is this a bug, a feature, or ...undefined behavior?

[kyle_]

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.

[Dark Photon]

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.

[kyle_]

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.

[Dark Photon]

Ok. I think we both agree that the spec language is a little misleading here.

For glClear I see:

When Clear is called, the only per-fragment operations that are applied (if enabled) are the pixel ownership test, the scissor test, sRGB conversion (see section 4.1.9), and dithering. The masking operations described in section 4.2.2 are also applied.

Writing of bits to each of the logical framebuffers after all per-fragment operations
have been performed may be masked. The commands ... ColorMask... DepthMask... StencilMask

but regarding glBlitFramebuffer...:

When values are written to the draw buffers, blit operations bypass most of the fragment pipeline. The only fragment operations which affect a blit are the pixel ownership test, the scissor test, and sRGB conversion

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.

Thanks.

[Alfonse Reinheart]

I've filed a bug requesting clarification, but considering how few bugs are ever noticed let alone fixed, I doubt anything will come of it.

[Ilian Dinev]

Don't worry, it's being actively discussed about . (I probably can't tell more)