Bug 89634 - dEQP-GLES3: sin, cos, tan do not correctly handle large inputs
Summary: dEQP-GLES3: sin, cos, tan do not correctly handle large inputs
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL: https://dri.freedesktop.org/wiki/I965...
Whiteboard:
Keywords:
: 86755 91213 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-03-18 07:02 UTC by Iago Toral
Modified: 2019-09-25 18:53 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Iago Toral 2015-03-18 07:02:49 UTC
List of affected tests:

dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_vertex.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_vertex.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_vertex.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_vertex.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_fragment.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_fragment.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_fragment.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.mediump_fragment.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_vertex.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_vertex.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_vertex.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_vertex.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_fragment.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_fragment.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_fragment.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.sin.highp_fragment.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_vertex.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_vertex.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_vertex.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_vertex.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_fragment.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_fragment.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_fragment.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.mediump_fragment.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_vertex.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_vertex.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_vertex.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_vertex.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_fragment.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_fragment.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_fragment.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.cos.highp_fragment.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_vertex.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_vertex.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_vertex.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_vertex.vec4
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_fragment.scalar
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_fragment.vec2
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_fragment.vec3
dEQP-GLES3.functional.shaders.builtin_functions.precision.tan.mediump_fragment.vec4

The GLES3 specs say that trigonometric functions do not have a defined precision, so I wonder if these tests are valid at all. However, it is true that for large enough angles the results have so much error that they are completely bogus. This can probably be fixed in software by rounding input angles to 0..2PI for example, but I woder if we want to take the cost of that considering that the precision error only becomes big enough for very large values of the input angle.

There was a brief discussion on the mailing list about this topic:
http://lists.freedesktop.org/archives/mesa-dev/2014-December/072429.html
Comment 1 Kenneth Graunke 2015-03-19 01:33:59 UTC
From the IVB PRM, Volume 4, Part 3:

"Absolute error <= 0.0008 for the range of +/- 100* pi

 Outside of the above range the function will remain periodic, producing values
 between -1 and 1. However, the period of COS is determined by the internal
 representation of Pi, meaning that as the magnitude of input increases the
 absolute error will, in general, also increase."

Given that sin and cos are extremely common in shaders, I'm rather loathe to emit extra shader instructions to try and make them more precise.  I imagine most angles used by real programs will be between [-100pi, 100pi].

You can definitely construct cases that break (even producing surprising results like sin(x) > 1.0), but as you say, the specification specifically states that there is no precision guarantee.
Comment 2 Ian Romanick 2015-07-06 19:48:51 UTC
*** Bug 91213 has been marked as a duplicate of this bug. ***
Comment 3 Ian Romanick 2015-07-06 20:11:24 UTC
We've now had a report of an actual user encountering this problem.  See bug #91213.

Most apps provide well conditioned data to the trig functions, and I'd prefer to not penalize their performance for the few apps that do not provide well conditioned data.  I think we should provide a drirc option to disable "correctness for huge angles."

We also have to be careful about how we reduce the angle.  The quality of the trig functions decreases as the magnitude of the angle increases.  In some applications wrapping from 2π to 0 could cause artefacts due to a discontinuity introduced in the derivative.

For whatever value of Kπ we choose, we want to wrap values on the range (Kπ, (K+1)π] to [-Kπ, Kπ].  Values on the range [-(K+1)π, -Kπ) should be treated similarly.  There may still be a discontinuity in the derivative, but that should minimise it.

So... the wrap function becomes ((a+Kπ) % 2Kπ) - Kπ, right?
Comment 4 samuel.vonstachelski 2015-07-29 14:42:42 UTC
Hello

I came across this thread while googling why on earth the cosine in my shader calculated wrong values.
The problem will appear as soon as a shader uses e.g. the system time for some procedural content. I played around with a tool that works similar to shadertoys.com, but as desktop application. There is a uniform iGlobalTime which is generated using the system time. And the value of that uniform (aka the time in seconds since the system started) is too high for the cosine most time (around 13500s think). On github we also discussed this bug: https://github.com/simon-budig/shadertoy/pull/3

Is there something happen about this issue?

>In some applications wrapping from 2π to 0 could cause artefacts due to a >discontinuity introduced in the derivative.
Ian, could you give me an example when artefacts would appear? I can not imagine when such artefacts would appear (I guess due to my average math knowledge).
Comment 5 Mark Janes 2016-06-10 17:22:22 UTC
This was fixed by mesa 65fbc43d54403905e3eaea02372b5a364dc1d773.

mesa d9546b0 subsequently uses drirc instead of the environment variable.
Comment 6 Ruslan Kabatsayev 2016-06-10 17:35:24 UTC
But what about bug #91213? It's marked as duplicate of this, but multiplication of SIN/COS results by 0.99997 done in commit 65fbc43d won't fix it.
Comment 7 Mark Janes 2016-06-10 19:58:40 UTC
You are right.  The input range bug is a separate issue from what dEQP flagged, but was marked as a duplicate.

I'll re-open this bug to track the remaining work.
Comment 8 Matt Turner 2016-11-02 02:07:34 UTC
*** Bug 86755 has been marked as a duplicate of this bug. ***
Comment 9 GitLab Migration User 2019-09-25 18:53:39 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/1478.


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.