Bug 89643 - dEQP-GLES3: dfdx/dfdy precision errors
Summary: dEQP-GLES3: dfdx/dfdy precision errors
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2015-03-18 07:43 UTC by Iago Toral
Modified: 2019-09-25 18:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Sample program reproducing the problem (3.20 KB, application/x-compressed-tar)
2015-03-18 07:48 UTC, Iago Toral
Output of the attached program showcasing the problem (41.55 KB, image/png)
2015-03-18 07:51 UTC, Iago Toral

Description Iago Toral 2015-03-18 07:43:04 UTC
List of affected tests:


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.
Comment 1 Iago Toral 2015-03-18 07:48:57 UTC
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.
Comment 2 Iago Toral 2015-03-18 07:51:26 UTC
Created attachment 114427 [details]
Output of the attached program showcasing the problem
Comment 3 Jason Ekstrand 2019-07-26 21:25:36 UTC
Is this still a thing?  If so, there's a chance that this MR affects it:

Comment 4 Paul 2019-07-29 11:09:14 UTC
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).
Comment 5 GitLab Migration User 2019-09-25 18:53:45 UTC
-- 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.