fp64 (64-bit Floating Point)
Provides basic 64-bit math support in GPU shaders:
| Function | Description |
|---|---|
vec2 add_fp64(vec2 a, vec2 b) | |
vec2 sub_fp64(vec2 a, vec2 b) | |
vec2 mul_fp64(vec2 a, vec2 b) | |
vec2 div_fp64(vec2 a, vec2 b) | |
vec2 sqrt_fp64(vec2 a) | |
vec2 exp_fp64(vec2 a) | |
vec2 log_fp64(vec2 a) | |
vec2 sin_fp64(vec2 a) | |
vec2 cos_fp64(vec2 a) | |
vec2 tan_fp64(vec2 a) |
The full fp64 function library is GLSL-only. It does not provide WGSL source,
so WGSL shaders cannot call exp_fp64, log_fp64, or its trigonometric
functions. For WebGPU, use the lower-level
fp64arithmetic
module, which supplies WGSL add, subtract, multiply, divide, and square-root
helpers.
The side-by-side Mandelbrot views show where fp32 loses detail as the animated zoom deepens. On
WebGPU, the example uses fp64arithmetic, and the panel below the canvases can
benchmark each arithmetic path on the active device:
Precision
WebGL and portable WGSL do not expose native 64-bit floating-point arithmetic.
The GLSL-only fp64 library and its cross-language fp64arithmetic dependency
instead represent a value as the unevaluated sum of two 32-bit floating-point
terms. This double-single representation can provide up to roughly 48
significant bits, or about 14 decimal digits, while remaining within the
exponent range of f32. It is not IEEE 754 binary64, which has 53 significant
bits and a much larger exponent range.
The classic double-single algorithms depend on specific intermediate rounding
points. This matters specifically to WGSL users of fp64arithmetic: WGSL
permits floating-point reassociation and fusion, so Apple WebGPU adapters
automatically select its integer-controlled implementation. The full fp64
library remains GLSL-only. See
GPU Floating-Point Precision Techniques
for a comparison with binary64, fixed point, exact origin-relative subtraction,
and the available double-single paths.
Historical WebGL testing on a 2015 MacBook Pro with an AMD Radeon R9 M370X measured these error bounds for the classic implementation:
Addition and subtraction: < 1 ulp
Multiplication: ~1.5 ulps
Division: ~2 ulps
Square root: ~2.6 ulps
Exponential: ~2.6 ulps
Logarithm: ~11.6 ulps (depends on the accuracy of native log() function)
Trigonometry: ~5 ulps
Note: ulp = unit in the last place
Performance Implications
Since extended-precision floating-point math is emulated using multiple operations, it costs significantly more GPU cycles than native 32-bit math (more than an order of magnitude, not to mention the non-IEEE compliant "fast-math" functions that most GPUs use to trade accuracy for speed).
However, by using 64-bit math only in accuracy critical paths, the performance impact of using 64-bit calculations will normally be significantly less than an order of magnitude.
For many applications, the amount of time spent in e.g. the vertex shading stage is only part of the time spent in the whole the rendering pipeline.
There is also a memory impact: vertex attributes and uniform data that use
double-single values require two f32 terms. Since a layer usually has other
attributes that do not require extended precision, the total memory impact is
normally less than 2x.