The following results are from WebGL port of this deqp test, but I think native case might be similiar.
Taking this case (fbo_float_vec2_highp) as example, at (x=97, y=2), 
threshold = [0.00006097555160522461, 9.80908925027372e-45, 0.000030502676963806152, 0.000030516646802425385]
On BDW machine:
reference = [0.8464646464646465, -0, -0.13636363636363638, -0.010101010101010102], resDerivate = [0.8464641571044922, -1.1920928955078125e-7, 0, 1]
On SKL machine:
reference = [0.8464646464646465, -0, -0.13636363636363638, -0.010101010101010102], resDerivate = [0.8464641571044922, 0, -0.13636398315429688, 1]

You may see, the 2nd value of derivate should be 0 (On both SKL and NVIDIA platform, it's 0 here), but I got -1.1920928955078125e-7 on BDW.

Actually there are two checkes there in LinearDerivateCase::verify() of es3fShaderDerivateTests.cpp, one is "verifyConstantDerivate(m_testCtx.getLog(), result, errorMask, m_dataType, reference, threshold, m_derivScale, m_derivBias, LOG_NOTHING)", while the other is “reverifyConstantDerivateWithFlushRelaxations(m_testCtx.getLog(), result, errorMask, m_dataType, m_precision, m_derivScale, m_derivBias, surfaceThreshold, m_func, function)”. Due to the non-zero value above, it fails with first check. But in second check, as the threshold there is "surfaceThreshold" (all 0s) instead of threshold (max(surfaceThreshold, opThreshold)), it fails sooner than in first check
Is it a problem here that we need to use threshold instead of surfaceThreshold in second check? I did a test, and it got these cases pass.

This test is not in the android "must pass" list:
https://android.googlesource.com/platform/external/deqp/+/master/android/cts/master/gles3-master.txt

Mesa's requirements are currently limited to the must-pass list.

(In reply to Mark Janes from comment #2)
> This test is not in the android "must pass" list:
> https://android.googlesource.com/platform/external/deqp/+/master/android/cts/
> master/gles3-master.txt
> 
> Mesa's requirements are currently limited to the must-pass list.

Hi, Mark, I think this case exists on must-pass list.
on line 15703 dEQP-GLES3.functional.shaders.derivate.dfdx.fbo.vec2_highp

Mark, sorry, I had checked these two cases again, they may be not the same cases.

Interestingly, the majority of the results are correct - there's just one tiny spot near the upper right corner that seems to be wrong.

Also, the copy I have of the "other driver" fails in exactly the same way...

I agree with Mark.  I don't think we can pass these.  It looks like they were removed from the mustpass list in:

commit ea026b329e6bf73f109cda914c90f08d5f7a5b8d
Author: Pyry Haulos <phaulos@google.com>
Date:   Tue Jul 21 15:12:53 2015 -0700

    Remove highp float FBO dfd*() tests from mustpass
    
    Bug: 22628471
    Bug: 22632003
    Change-Id: Ia9d2b9a5e04ad317cbcc8782c9efaeedd94a0a58

Sadly, the commit messages offer no explanation as to why, and I believe those bug IDs are for a Google-internal bug tracker.  (I suppose we could ask Pyry.)

Having looked around for documentation that could explain the problems, I found
https://hsdes.intel.com/appstore/article/#/1208680029/main
which indicates that the Intel Android team isn't planning on fixing these tests either.

I found another HSD somewhere which suggested this comes down to numerical imprecision when interpolating inputs, and that testing dFdx is hard.  I'm guessing that Skylake must have gotten a little better in that regard; these tests fail on both Broadwell and Haswell, despite us using the exact same code.

So I don't think we can fix this.  Someone will probably want to follow up with the WebGL conformance developers and Google developers and remove tests ported from blacklisted dEQP tests.

Sorry :(

We had find an issue when porting from the native code to webgl code, https://github.com/KhronosGroup/WebGL/pull/1931. After correcting it, we found that this issue passed on chrome.
And we had debugged why it passed on chrome and failed on native code, the root cause is interpolation value range is different between webgl and native, but the dfdx value is nearly same. For example, dfdx value of the same pixel R channel,
Native:
interpolation value range: [0.84646081924438477 0.84647130966186523]
dfdx value: 0.846460342 does not be in range, so fail.

WebGL:
interpolation value range: [0.846458911895752 0.8464700281620026]
dfdx value: 0.8464603424072266 does be in range, so pass.

It seems that the range computed by CPU(native) and JS(WebGL) is different, We suspect that the range computed by JS(64-bits) is more precise, so it is reasonable that passes on WebGL. I hope the info is useful for you. Thank you.