A lot of dEQP tests fail when run in FBO mode with 32-bit depth and 8-bit stencil. You can activate this mode by passing --deqp-surface-type=fbo --deqp-gl-config-name=rgba8888d32s8.
./deqp-gles2 --deqp-surface-type=fbo --deqp-gl-config-name=rgba8888d32s8 --deqp-case=dEQP-GLES2.functional.fragment_ops.depth_stencil.stencil_depth_funcs.no_stencil_depth_always
Notably, d32s0 works, as do d16s8 and d24s8.
It seems that the cause of this is a bug in dEQP, that confuses the number of bits in the stencil buffer with the number of bits in the depth buffer when it renders the reference image.
Specifically, the test passes the depthBits where it should be passing stencilBits (so 32 where it should be using 8). As result, when it uses the number of stencil bits here:
int maskedVal = clear.stencil & ((1<<stencilBits)-1);
The result of ((1<<stencilBits)-1) overflows and causes incorrect result in maskedVal (the value to clear the stencil buffer to). For values of stencilBits that do not cause overflow (so 24, 16 or 8), the result of the AND operation leads to the same result as if we passed the correct number of stencil bits. That explains why the test only fails when we have 32b depth and stencil > 0b.
This patch to dEQP fixes the specific test case mentioned in the bug report and should fix others as well:
diff --git a/modules/gles2/functional/es2fDepthStencilTests.cpp b/modules/gles2/functional/es2fDepthStencilTests.cpp
index 793c7a3..eacda9e 100644
@@ -669,7 +669,7 @@ DepthStencilCase::IterateResult DepthStencilCase::iterate (void)
translateCommand(testCmd, refTestCmd, m_renderTarget);
// Base clears.
- renderReference(m_baseClears, m_refColorBuffer->getAccess(), m_refStencilBuffer->getAccess(), m_renderTarget.depthBits);
+ renderReference(m_baseClears, m_refColorBuffer->getAccess(), m_refStencilBuffer->getAccess(), m_renderTarget.stencilBits);
// Base depths.
for (vector<RefRenderCommand>::const_iterator cmd = m_refBaseDepthRenders.begin(); cmd != m_refBaseDepthRenders.end(); ++cmd)
Based on the previous comment I suggest we close this as RESOLVED/NOTOURBUG
(In reply to Iago Toral from comment #2)
> Based on the previous comment I suggest we close this as RESOLVED/NOTOURBUG
Thanks, done. Feel free to make the change yourself in the future.
I submitted Iago's patch as:
Patch landed in dEQP as commit d8d17bc4d9d9a3b2f9215ba04cbb9891dcf54ab1.