List of affected tests:
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:
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.
*** Bug 91213 has been marked as a duplicate of this bug. ***
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?
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).
This was fixed by mesa 65fbc43d54403905e3eaea02372b5a364dc1d773.
mesa d9546b0 subsequently uses drirc instead of the environment variable.
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.
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.
*** Bug 86755 has been marked as a duplicate of this bug. ***
-- 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.