<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - dEQP-GLES3: dfdx/dfdy precision errors"
href="https://bugs.freedesktop.org/show_bug.cgi?id=89643">89643</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>dEQP-GLES3: dfdx/dfdy precision errors
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr>
<tr>
<th>Version</th>
<td>git
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Drivers/DRI/i965
</td>
</tr>
<tr>
<th>Assignee</th>
<td>idr@freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>itoral@igalia.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-3d-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>