<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES3: sin, cos, tan do not have enough precision" href="https://bugs.freedesktop.org/show_bug.cgi?id=89634#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - dEQP-GLES3: sin, cos, tan do not have enough precision" href="https://bugs.freedesktop.org/show_bug.cgi?id=89634">bug 89634</a> from <a class="email" href="mailto:idr@freedesktop.org" title="Ian Romanick <idr@freedesktop.org>"> Ian Romanick</a> <pre>We've now had a report of an actual user encountering this problem. See <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED DUPLICATE - GLSL sine and cosine of argument larger than 4096*pi give wrong results" href="show_bug.cgi?id=91213">bug #91213</a>. 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?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>