Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 8 of 8

Thread: fp64 (double-precision) ULP errors?

  1. #1
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    5

    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.

  2. #2
    Advanced Member Frequent Contributor arekkusu's Avatar
    Join Date
    Nov 2003
    Posts
    782
    It says: "The precision of double-precision operations is at least that of single precision."

    Whatever that means.

  3. #3
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    5
    Thanks. That's a lot less precise than I hoped for
    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.

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by rahulgarg View Post
    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.
    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?

  5. #5
    Junior Member Newbie
    Join Date
    May 2013
    Posts
    5
    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.

  6. #6
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    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.

  7. #7
    Member Regular Contributor
    Join Date
    Jun 2013
    Posts
    490
    Quote Originally Posted by arekkusu View Post
    It says: "The precision of double-precision operations is at least that of single precision."

    Whatever that means.
    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.

  8. #8
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,144
    Quote Originally Posted by GClements View Post
    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.
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •