List of affected tests: dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec2_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec2_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec2_highp dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec3_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec3_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec3_highp dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec4_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec4_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fbo_float.vec4_highp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec2_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec2_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec2_highp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec3_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec3_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec3_highp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec4_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec4_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.fastest.fbo_float.vec4_highp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec2_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec2_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec2_highp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec3_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec3_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec3_highp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec4_lowp dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec4_mediump dEQP-GLES3.functional.shaders.derivate.dfdx.nicest.fbo_float.vec4_highp The tests check derivative of a float, a vec2, a vec3 and a vec4 respectively. For this they render a quad using two triangles and for each vertex they pass a coord parameter (a float, vec2, vec3 or vec4 parameter depending on the test) that they use to compute the derivative. For the second component of this coord parameter there seems to be a precision error after computing its derivative (that is why the float tests work fine, because they only use the first and only component but it fails for all the other cases, since all vec types have at least two components). In these cases that fail, the argument of the derivative is constant in X, so the result is expected to be 0, however, the actual result is slightly different from 0 for a number of pixels. More specifically, of the two triangles rendered, one of them is perfect (the derivative is perfect 0 for all pixels) while the other packs some level of noise in almost all of its pixels (the highest level of noise is in the order of 10^-6, so it is not too big, but big enough for deqp to complain). A few things worth mentioning: - The problem also exists for dfdy, but for some reason the deqp tests for dfdy do not catch this. - The fact that this only happens for one of the two triangles is very weird. Altering the order in which the triangles are rendered does not change the result. - The implementation of dfdx and dfdy seem straight forward enough (it is basically a subtraction of two values), that it is hard to imagine that the cause of this may live in the driver code but I can probably be missing something. I checked that the source of the problem are not the color values computed for the gradient: if I paint the gradient, and then read the pixels, I see the exact same color for all the pixels in the same row/col (depending on the direction of the gradient), even across the two triangles in the quad, so the source data for the dfdx/dfdy operations seems to come without precision errors. That means that the error is produced by the dfdx operation itself.
Created attachment 114426 [details] Sample program reproducing the problem This renders a quad with two triangles. The fragment shader will compute a derivative like the dEQP tests and use the result as the output color (so it should be all black if no precision errors are present). If there is a precision error > 1.0e-8 for a fragment it will render that fragment in green. The output shows how one of the two triangles is rendered in black and the other one has plenty of fragments in green. The test program uses libglm.
Created attachment 114427 [details] Output of the attached program showcasing the problem
Is this still a thing? If so, there's a chance that this MR affects it: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1467
Hello guys I've reproduced the issue from attached test on the HSW with ubuntu 18.10 and 4.18.0 version of the Kernel. Test failed on 18.2.8 version of the mesa and also on the latest master version with applied patch from MR 1467 . Additionaly, I've checked the issue on KBL and SKL - test passed. According to the CI results (https://mesa-ci.01.org/mesa_master_daily/builds/5134/group/a722c42c505377282428199002691759) , I think test will fail on machines with 8th generation (bdw and bsw).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1480.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.