[Piglit] [PATCH] CL: Fix check of ULP when probing float/double results

[Aaron Watry]

On Tue, Dec 29, 2015 at 2:28 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Tue, Dec 29, 2015 at 3:18 PM, Aaron Watry <awatry at gmail.com> wrote:
> > Regardless of whether 0.0 is the absolutely correct answer for
> > cos(1.57079632679), we can hopefully all agree that -4.0 is NOT a valid
> > answer for cosine of anything
>
> Right so that's clearly wrong :) I was largely warning you about some
> of the issues we ran into trying to compute ULPs, and especially
> combining them with each other. The GL_ARB_shader_precision text is
> quite precise and similarly difficult to test -- e.g. fma() is allowed
> to be fused or non-fused, at the implementation's option. But that
> causes all sorts of results to be way different.
>
> Perhaps you don't have these issues in the OpenCL specs.
>
>
Answers, hopefully?

With regards to FMA(a,b,c):
CL 1.2, Section 6.12.2 says:
"Returns the correctly rounded floating-point
representation of the sum of c with the infinitely
precise product of a and b. Rounding of
intermediate products shall not occur. Edge case
behavior is per the IEEE 754-2008 standard."

Rounding mode is also called out in section 6.12.2:
"The built-in math functions are not affected by the prevailing rounding
mode in the calling
environment, and always return the same value as they would if called with
the round to nearest
even rounding mode."

CL 1.2, section 7.4:
"In this section we discuss the maximum relative error defined as ulp
(units in the last place).
Addition, subtraction, multiplication, fused multiply-add and conversion
between integer and a
single precision floating-point format are IEEE 754 compliant and are
therefore correctly
rounded. Conversion between floating-point formats and explicit conversions
specified in
section 6.2.3 must be correctly rounded."
<SNIP >
"The reference value used to compute the ULP value of an
arithmetic operation is the infinitely precise result."

So, we will still have to deal with the discrepancy between the infinitely
precise result and the rounded "expected" result when calculating our
ULP-based tolerances, but as already covered in the previous email, the
absolute tolerance was definitely wrong.

CL has a set of native_* functions that allows the implementation to choose
how to calculate the result.
Example: native_cos(x), which has implementation-defined precision, but
allows the vendor to optimize as they see fit while possibly sacrificing
accuracy.

Most of the time, I've seen the native_* functions used to call the
hardware implementation of those instructions, while the non-native ones
are implemented in CL C to achieve the required precision.

--Aaron




>   -ilia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20151229/844ffa65/attachment.html>