[Bug 97002] dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float_vec2_highp fails

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97002

--- Comment #1 from Yang Gu <yang.gu at intel.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20160720/6510a848/attachment.html>