Fp64 (double-precision) ULP errors?

I have been trying to find out if the GLSL specification (as per OpenGL 4.3) specifies any precision or error bounds for fp64 operations. For fp32 (float), the errors are specified as ULPs. I am not sure if the same error bounds apply for fp64. I am hoping tighter bounds are specified for fp64 than fp32.

It says: “The precision of double-precision operations is at least that of single precision.”

Whatever that means.

Thanks. That’s a lot less precise than I hoped for :frowning:
For comparison, OpenCL and CUDA both define that add, mul and divide on fp64 is correctly rounded and HLSL defines add and mul as correctly rounded and divide as within 0.5 ULP. GLSL defines divide as within 2.5 ULP for fp32, and if the same applies for fp64, would imply 2.5 ULP for fp64 divide.

Precision of the calculation depends on both hardware and compiler implementation. The hardware implementation defines highest precision of all built-in instructions, while compiler is responsible for conversions, combining instructions and emulation (software implementation).

The precision of calculation is usually expressed in ULPs. It is really the most convenient way. What do you mean with “tighter bounds”? If it is said that DP function generates the same error as SP one in ULPs, it implies much higher accuracy considering represented values.

GLSL spec. requires lower accuracy in order to support wider range of hardware. You should rather follow vendors specification for a particular hardware. Btw, older graphics cards are not even IEEE754 complaint.

If addition and multiplication are IEEE-compliant, they have a maximum error of 0.5 ULP. However, the compiler often combines them into a single FMAD instruction and for NV devices of compute capability 1.x, FMAD truncates the intermediate result of the multiplication. Also, division and square root are implemented as reciprocals and are not compliant to the standard.

After this short discussion, may I ask you why do you need this? :slight_smile:

Thanks a lot Aleksandar! We have been looking into using GLSL + Compute Shaders as an alternative to CUDA and OpenCL for some scientific computing applications. Precision is one of the things I have been looking into. I am not a numerical analyst myself, but I am trying to understand what to expect so that I can explain it to users. Currently the somewhat weak guarantees from the standard is not inspiring confidence, and we will likely stick to OpenCL where the standard is paying more attention to precision.

Compute shaders should not be a replacement for CUDA/OpenCL, especially if transcendental functions are used (take a look at some of my previous posts). I don’t know what you want to achieve, but if precision is important stick to CUDA/OpenCL. If performance is the primary goal, then compute shaders are good choice since interop could slowdown your application.

[QUOTE=arekkusu;1252363]It says: “The precision of double-precision operations is at least that of single precision.”

Whatever that means.[/QUOTE]

I understood it as meaning that the implementation is free to simply convert double-precision values to single precision, perform all calculations using single precision, then convert the results back to double precision.

IOW, it doesn’t require the hardware to actually support double precision, it just has to be able to interface with code which uses double-precision representation for its data.

[QUOTE=GClements;1252439]I understood it as meaning that the implementation is free to simply convert double-precision values to single precision, perform all calculations using single precision, then convert the results back to double precision.
IOW, it doesn’t require the hardware to actually support double precision, it just has to be able to interface with code which uses double-precision representation for its data.[/QUOTE]

It can be interpreted so, but it is not how GLSL compilers are implemented.
I won’t add more comments, just try to compile shaders with DP variables with the driver/card that does not support them.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.