dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex passes reliably for me on all intel platforms.

For SNB, I have a record of it being fixed by mesa 58d4751fa0c5a38069879e9f72047b75f8351d93

What platform are you testing the native dEQP test on, and what version of mesa?

Our tests against BDW and SKL on Ubuntu with both driver 11.2 (default in System) and ToT (12.1) would fail. 
BTW, we get dEQP tests from "https://android.googlesource.com/platform/external/deqp". Any problem here?

Mark, I think you're running with --deqp-gl-config-name=rgba8888d24s8, while Yang might be getting rgba8888d32s8?

I tried with option "--deqp-gl-config-name=rgba8888d24s8", but it still failed. Actually this case was ported to WebGL2 conformance test suite (CTS), and I met same error there. So I wonder if this is a Mesa issue, or I should do some changes on the test case itself.
What's your full command line to run this case successfully on Linux?

Created attachment 125160 [details]
error mask

FWIW it also fails for me on SKL with the following deqp checkout:

$ git describe
android-n-preview-2-3424-gf4f3d80

I believe this is in the deqp-dev branch. [I wanted to get the GLES 3.2 tests.]

I've run it both with --deqp-visiblity=hidden and without. Both 12.0.1 and mesa master(ish).

./deqp-gles3 --deqp-visibility=hidden --deqp-case=dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex

Attached is the error mask.

I apologize for the confusion.  I searched for that test in Mesa's CI results, which have slightly different names due to the way piglit renames tests.

I was looking at:
deqp-gles3.functional.shaders.texture_functions.texture.sampler2dshadow_vertex
instead of 
dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex
                                                                 ^^^^^

The "array" variant of this test is not in the deqp "must pass" list, which is the current requirement for Intel's Mesa team:

https://android.googlesource.com/platform/external/deqp/+/master/android/cts/master/gles3-master.txt

You may be interested to know that it does pass with both llvmpipe and softpipe.

FWIW, dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex passes for me on Haswell, but not Broadwell or Skylake.

I found out why: Haswell doesn't advertise Z16 support, so it falls back to Z24, which works perfectly.  Broadwell does, so it uses actual Z16, and fails.

Forcing Haswell to use Z16 makes it fail, and forcing Broadwell to use Z24 makes it work.

So now the question is: why is Z16 broken?

(In reply to Kenneth Graunke from comment #9)
> So now the question is: why is Z16 broken?

And why only in non-fragment shaders, for array surfaces.

Other differences between non-array and array:

256x256 vs 128x128
9 lod vs 1 lod

And frag shaders get to use sample_c instead of sample_l_c or sample_c_lz. [Forcing it to use sample_l_c on SKL had no effect.]

Can this bug be closed?

I'm afraid not. I just had a try with latest mesa (a61528fa33f8d7f39167e62da6d9317ed84c43b8), and the failure is same.

I don't think there's anything we can do about this (so, closing as WONTFIX).

Several vendors cannot pass this test using Z16, which is why it was blacklisted.  The test apparently does ref < (float) depth, whereas some hardware does (16-bit fixed point) ref < depth.  Comparing Z16 fixed point values obviously has less precision than comparing IEEE floats...so such implementations fail the test (but are actually valid).

Thanks for clarification. We will try to modify the test case to make it more tolerant.