KhronosGroup / KhronosGroup/OpenCL-Docs
SPIR-V Environment Spec does not describe required accuracy for OpFMod and OpFRem
- Dominant language
- Python
- Stars
- 420
- Forks
- 131
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 11
Description
See related discussion: https://github.com/KhronosGroup/OpenCL-CTS/issues/1548
In short, the OpenCL SPIR-V environment spec currently does not describe the required accuracy for the **OpFMod** and **OpFRem** instructions (although it does describe the required accuracy for the `fmod` and `remainder` extended instructions).
OpenCL SPIR-V environment spec reference:
https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_ulp_values_for_math_instructions_full_profile
The spirv_new CTS tests are currently testing that **OpFMod** and **OpFRem** matches the behavior of these OpenCL C instructions, which may or may not be correct:
```c
#define spirv_frem(a, b) fmod(a, b)
#define spirv_fmod(a, b) copysign(fmod(a,b),b)
```
For Vulkan, the accuracy of **OpFMod** and **OpFRem** is derived from `trunc` and `floor`, which makes them cheap but potentially highly inaccurate:
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#spirvenv-op-prec
> The OpFRem and OpFMod instructions use cheap approximations of remainder, and the error can be large due to the discontinuity in trunc() and floor(). This can produce mathematically unexpected results in some cases, such as FMod(x,x) computing x rather than 0, and can also cause the result to have a different sign than the infinitely precise result.
What do we want to do for OpenCL?
Contributor guide
Assessment
This issue has not been assessed yet.