deqp stencil_value_mask_get* fail if run separately
Due to suspiscion of issues with lima that could be happening and hidden in deqp due to a dirty shared context, I ran deqp tests individually and compared against a full sequential run. The only differences were in this following block of tests:
dEQP-GLES2.functional.state_query.integers.stencil_value_mask_getboolean PASS dEQP-GLES2.functional.state_query.integers.stencil_value_mask_getinteger FAIL dEQP-GLES2.functional.state_query.integers.stencil_value_mask_getfloat FAIL
They pass if run in sequence, but
stencil_value_mask_getfloat fail if run separately.
With some more investigation I found that it also fails on i965 the same way:
$ ./deqp-gles2 --deqp-surface-width=256 --deqp-surface-height=256 --deqp-visibility=hidden --deqp-log-images=disable --deqp-crashhandler=enable --deqp-surface-type=pbuffer -n dEQP-GLES2.functional.state_query.integers.stencil_value_mask_getfloat
It seems that the value of
gl_context.Stencil.ValueMask (returned in the query for
GL_STENCIL_VALUE_MASK) is initialized to
_mesa_init_stencil) which when converted to float in the
stencil_value_mask_getfloat test, is different than what is expected by deqp. However when the tests run in sequence, it eventually gets assigned
0xffffffff which remains in the dirty context, and that makes the conversion and test pass.
It's not totally clear to me if this is a bug in mesa due to the type conversion or initialization or a bug in deqp. At this point it doesn't seem like a driver specific bug anymore. Any hints?