[Mesa-dev] Precision of float and trigonometric functions on i965
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.0(...) | 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Precision of float and trigonometric functions on i965
On 12/11/2014 11:59 AM, Iago Toral wrote: 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.0(...) | 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... According to the hw specs, sin and cos absolute error is = 0.0008, but only for the range of +/- 100 * pi. -- Petri Latvala ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Precision of float and trigonometric functions on i965
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 ito...@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.0(...) | 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Precision of float and trigonometric functions on i965
On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote: 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. Probably related to this: https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Precision of float and trigonometric functions on i965
On Dec 11, 2014 11:13 AM, Ilia Mirkin imir...@alum.mit.edu wrote: On Thu, Dec 11, 2014 at 2:10 PM, Chris Forbes chr...@ijw.co.nz wrote: 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. Probably related to this: https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ That's a fun article, but beside the point for what we probably care about. No one cares about precisely computing sin(pi) to hundreds of decimal places on a GPU. If we really want to fix the issue, we can do range reduction at the cost of probably a couple extra instructions. That said, I doubt this will be an issue in real life as x % pi begins to get fairly imprecise at those magnitudes. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
