On Tue, Dec 29, 2015 at 2:28 PM, Ilia Mirkin <[email protected]> wrote:
> On Tue, Dec 29, 2015 at 3:18 PM, Aaron Watry <[email protected]> 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 >
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
