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

[Iago Toral]

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