Builtin function precision is backend specific #511
Conversation
Resolve conflicting wording about the precision requirements of the builtin math functions. The introductory paragraph of section 4.17 "SYCL built-in functions for SYCL host and device" says that the precision is defined by the backend. However, the descriptions in section 4.17.4 "Math functions" and 4.17.6 "Half precision math functions" specified a required precision for all backends. Resolve this by removing the the wording in 4.17.4 and 4.17.6. (See issue KhronosGroup#507 for more on this.) Also add a new section to the OpenCL backend specification stating that the precision of these builtin math functions for the OpenCL backend matches the precision of the corresponding functions in the OpenCL specification. There are a few other related changes in this PR: * Clarify that the native precision and half precision functions are available in both host and device code (see issue KhronosGroup#509). * Remove a statement that the geometric functions use round to nearest even rounding mode. This also seems backend specific, and it doesn't even make sense for the OpenCL backend. See OpenCL issue KhronosGroup/OpenCL-Docs#1024 for more details on this. * Editorial changes to remove gratuitous references to OpenCL in the introductory paragraphs. * Editorial changes to make the introductions of sections 4.17.4 - 4.17.10 read consistently. Closes KhronosGroup#507 Closes KhronosGroup#509
|
Call for reviewers here ... |
| namespace [code]#sycl::native#. | ||
| The functions that are available within this namespace are specified in | ||
| <<table.native.math.functions>>. | ||
| <<table.native.math.functions>> describes the native precision math functions |
There was a problem hiding this comment.
Here we describe the functions in the native namespace as native precision math functions, but if we are removing the precision requirement of the regular math functions, this term becomes less meaningful. Maybe we should introduce some wording which states that the regular math functions are intended to be precise, whereas the native math functions are intended to be faster at the cost of precision, even as a non-normative note?
There was a problem hiding this comment.
Yes, I think that makes sense. I can add a paragraph similar to the one I added below for the half-precision functions. I'll have to think how to differentiate the half-precision functions from the native-precision ones, though. They are both defined by the backend and both trade off precision for performance.
There was a problem hiding this comment.
I addressed this in 56196d2.
|
Co-authored-by: Gordon Brown <[email protected]>
Better clarify the intent of the `sycl::native` and `sycl::half_precision` math functions.
I looked at the OpenCL C specification to see how they define the half-precision functions. The only limitation I saw on input values was for I don't think we need to say anything more about legal input values in the SYCL spec. |
|
WG approved to merge. |
KhronosGroup/SYCL-Docs#511 essentially removed any precision guarantees for math built-ins invoked on host and this PR aligns CTS with that direction.
Builtin function precision is backend specific
Builtin function precision is backend specific (cherry picked from commit e0486e5)
Builtin function precision is backend specific (cherry picked from commit e0486e5)
Resolve conflicting wording about the precision requirements of the builtin math functions. The introductory paragraph of section 4.17 "SYCL built-in functions for SYCL host and device" says that the precision is defined by the backend. However, the descriptions in section 4.17.4 "Math functions" and 4.17.6 "Half precision math functions" specified a required precision for all backends. Resolve this by removing the the wording in 4.17.4 and 4.17.6. (See issue #507 for more on this.)
Also add a new section to the OpenCL backend specification stating that the precision of these builtin math functions for the OpenCL backend matches the precision of the corresponding functions in the OpenCL specification.
There are a few other related changes in this PR:
Clarify that the native precision and half precision functions are available in both host and device code (see issue Are builtin "native" and "half-precision" functions available in host? #509).
Remove a statement that the geometric functions use round to nearest even rounding mode. This also seems backend specific, and it doesn't even make sense for the OpenCL backend. See OpenCL issue geometric functions and rounding modes OpenCL-Docs#1024 for more details on this.
Editorial changes to remove gratuitous references to OpenCL in the introductory paragraphs.
Editorial changes to make the introductions of sections 4.17.4 - 4.17.10 read consistently.
Closes #507
Closes #509