Include clarification for the imprecision that mod() can legally have
mbechard opened this issue · comments
Many of my users of run into the issue where they are getting mod(x, x) == x, and are confused since the GLSL docs don't mention this being a possible output. Talking to Nvidia, this seems expected, and the Vulkan spec specifically says so:
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.
This occurs on OpenGL as well though, but I'm assuming this behavior is just expected in general on GPUs, but not documented in GLSL. Should it be, or should OpenGL implementations of GLSL be more accurate and not be allowed to return mod(x, x) == x?
This was discussed in the OpenGL working group and the clarification from Vulkan is intended to apply in GLSL as well. It will be added in a future revision of the GLSL spec.
The clarification is now in the published version of the spec.