ULP requirements for fp16 divide

[lakshmih]

Referring to OpenCL C spec on ULP requirements

ULP requirements for single precision divide (x/y) and reciprocal(1.0/x) are ≤ 2.5 ulp

However, for half precision these are defined as needing to be 'correctly rounded'

We would like to propose that these be defined with specific (lower) ULP, following the pattern for other built-ins.
We would further like to set a precision requirement of <= 1 ulp for both of these cases for fp16.

Double precision ULP for these cases also suffer from the same discrepancy (specific ULP for float, correctly rounded for double) so these should be reviewed as well.

[svenvh]

As an additional consideration, for fp32 the specification defines the CL_FP_CORRECTLY_ROUNDED_DIVIDE_SQRT value for the CL_DEVICE_SINGLE_FP_CONFIG query:

CL_FP_CORRECTLY_ROUNDED_DIVIDE_SQRT - divide and sqrt are correctly rounded as defined by the IEEE754 specification.

In case implementations want to keep advertising a correctly rounded divide for half/double, we could consider extending the CL_DEVICE_HALF_FP_CONFIG and CL_DEVICE_DOUBLE_FP_CONFIG with CL_FP_CORRECTLY_ROUNDED_DIVIDE_SQRT. That may also require revisiting the sqrt ULP requirements.

[bashbaug]

Discussed in the November 5th teleconference. The decisions we need to make are:

1. Should we reduce the precision requirements for an fp16 divide? (Leaning towards “yes”.)
2. If we reduce the precision requirements for an fp16 divide, what should we reduce it to? <=1ULP? <=0.5ULP? Something else?
3. Do we need a build option like “-cl-fp32-correctly-rounded-divide-sqrt” to get back to a more precise fp16 divide?
4. Do we want to relax the precision requirements for any other fp16 operations, or is this just an issue with the fp16 divide? Consider 1/x in particular.
5. Do we want to relax the precision requirements for any fp64 operations?

[kpet]

See related CTS issue: KhronosGroup/OpenCL-CTS#1996

[lakshmih]

Agreed on WG call 11/12 to:

• Fix fp16 CTS tests for divide, reciprocal and sqrt to use the correctly rounded reference values. Covered in Mobica issues correctly rounded divide test for half is not using a correctly rounded reference OpenCL-CTS#1996 Re-enable reciprocal test in math_brute_force suite OpenCL-CTS#2145 and test for fp16 sqrt is not using a correctly rounded reference OpenCL-CTS#2146
• Once this is done, all vendors will run CTS to check if they pass and if not, what ULP values are acceptable
• Based on above results and discussion, amend the spec to reflect changes to fp16 ULP values

[bashbaug]

With our current GPU implementation, we have a 0.5 ULP error with some inputs:

ERROR: divide: 0.500000 ulp error at {0x1.ef4p-4 (0x2fbd), -0x1.cp+13 (0xf300)}
Expected: -0x1.1cp-17  (half 0x808e) 
Actual: -0x1.1ap-17 (half 0x808d) at index: 13227

If I relax the ULP requirements to 0.5 ULP then the test passes:

  1:          divide fp16     ................passed        0.50 @ {-0x1.0e4p-6, 0x1.7p+13}

Tested on an Arc A750 with the command line: test_bruteforce -f -r divide

Our current CPU implementation passes without relaxing the ULP requirements.

[lakshmih]

Qualcomm would like to request 1 ULP for divide.

[paulfradgley]

0.5 or 1 ULP are fine for IMG.

[lakshmih]

As agreed on 1/7/2025, steps towards resolution on this:

• Qualcomm to update spec PR to restrict to divide and push test PR to update ULP to 1.0 for divide. Once vendors agree that the CTS update is good, review and merge both.
• Re-enable reciprocal in CTS. Qualcomm can push this as well (patch to re-enable the test). Run and check results and depending, make changes to spec(s) and CTS to update to 1.0. If there are other changes needed to re-enable the test, we might have to figure out how to address those.
• Wait for mobica to fix sqrt CTS and proceed similarly with spec/test updates based on results on implementations.