[Mesa-dev] Precision of float and trigonometric functions on i965

[Chris Forbes]

Iago,

This doesn't matter for GL conformance -- but the impression I get is
that dEQP is aiming at something more.

In any case, the usual problem with this is inaccurate range
reduction, which is fixable in software at some performance cost. The
C library does this, for example.

- Chris

On Thu, Dec 11, 2014 at 10:59 PM, Iago Toral <itoral at igalia.com> wrote:
> Hi,
>
> there are a bunch of dEQP tests that check precision of trigonometric
> functions and float qualifiers that fail on i965. The way these tests
> usually operate is that they define a float (with a lowp, mediump or
> highp precision qualifier) and assign the result of a trigonometric
> function to it. Then they check if the result is within the limits of
> the precision expected for that precision qualifier.
>
> However, reading the GLSL spec I see:
>
> "4.5.1 Range and Precision
> ...
> Built-in functions not listed above and not defined as equations of the
> above have undefined precision. These include, for example, the
> trigonometric functions and determinant."
>
> So according to this I think these tests are wrong: you can't test
> precision on the result of a function that has undefined precision... if
> the purpose of these tests is to check precision of trigonometric
> functions that should be plain wrong, if it is to test the precision of
> float qualifiers I understand they should use functions or float
> operations that have defined precision expectations according to the
> spec.
>
> That said, I also noticed that most of the errors reported are for
> fairly big numbers, so I played a bit with some examples and noticed
> that trigonometric functions lose more precision as their argument gets
> bigger. If I pass arguments of a few thousand radians to sin() or cos()
> I usually get results that are off by >0.1 and for many values over
> 15000 radians I get completely bogus results, off by more than 0.5 of
> even 1.0 in some cases. Some examples:
>
> Angle in radians   | sin() result | Expected     |  Error   |
> 13000.0            | 0.05308(...) | 0.08947(...) | ~ 0.036  |
> 14000.0            | 0.85559(...) | 0.87388(...) | ~ 0.018  |
> 15000.0            | 0.00018(...) | 0.89324(...) | ~ 0.893  |
> 16000.0            | 0.82698(...) | 0.13100(...) | ~ 0.696  |
> 24500.0            | 0.00000(...) | 0.95833(...) | ~ 0.958  |
>
> I suppose this is a known issue, right? Also, considering that sin() is
> implemented as a single Math hardware instruction I imagine there is
> little that software can do to correct this in any case...
>
> Iago
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev