Research-1403: FMA contraction off for every CUDA kernel — which kernels change, what each twin does against the CPU, what it costs¶

• Status: Active
• Workstream: ADR-1403, ADR-1367, ADR-0214
• Last updated: 2026-10-01

Question¶

T-CUDA-FP-CONTRACT-DEFAULT-2026-09-29: nvcc fuses a * b + c into one FMA by default, and only six of the 21 CUDA fatbins were built with --fmad=false. The CPU reference and, since ADR-1367, every SYCL twin do not contract. If every CUDA kernel is built without contraction: which kernels' code changes, which twins move against --backend cpu, does any twin rely on a fused operation, and what does a 3840x2160 frame cost before and after?

Sources¶

• core/src/meson.build (cuda_cu_sources, the fatbin custom_target), core/src/feature/cuda/**/*.cu, the CPU extractors they mirror.
• RTX 4090 (sm_89, driver 615.71.09), nvcc 13.4.92, gcc 16.2.1, glibc 2.44, Ryzen 9 9950X3D. meson setup <dir> core -Denable_cuda=true -Denable_sycl=false --buildtype=release -Db_lto=false. Before: master bd061d95a. After: the same plus this change. (Two earlier rounds measured the same numbers for every twin they did not concern: on 2c3acf1c9, before ADR-1397 gave psnr_hvs_score the flag and its CPU-order sum, and on bd17c352f, before ADR-1399 rewrote ssim_score.cu with explicit rounding intrinsics. The float_ms_ssim steps in finding 3 and the fp64 cost are from the first round, the timings in finding 5 from the second.)
• Fixtures, 8-bit 4:2:0, --precision max: the Netflix pair src01_hrc00/01_576x324 (48 frames), the checkerboard pairs checkerboard_1920_1080_10_3_0_0 against _1_0 and _10_0 (3 frames each), and the first 50 frames of BBB 3840x2160 (testdata/bbb/ref/dis_3840x2160_200f.yuv).
• Every twin is requested by its registered name (--backend cuda --feature <name>_cuda), the CPU extractor with --backend cpu --threads 16.

Findings¶

1. Fifteen fatbins keep their machine code, six change¶

cuobjdump -sass of every fatbin, before against after, for each shipped architecture (sm_80, sm_86, sm_89, sm_90, sm_100, sm_120); FMA counts are the sm_89 cubin's.

For the nine identical ones the only difference in the fatbin is the PTX text: mul.f32 / mul.f64 become mul.rn.f32 / mul.rn.f64 and the header gains ptxasOptions = --fmad false. nvcc had formed no FMA from their source: the FMAs counted in adm_cm, adm_csf and ssim_score are in the PTX of neither build, they are the back end's own expansion of division and square root. The FMAs that remain in the changed kernels after the flag are of that kind (division, square root, libdevice math functions), plus the explicit ones.

2. Per-twin agreement with the CPU, before and after¶

Identical frame outputs / all frame outputs (every output of the twin, every frame), then the largest and the mean absolute difference over them. "Same" means the twin's own value is unchanged on every frame.

float_ssim_cuda runs at every scale since ADR-1399 and was bit-identical before this change; on the previous base (bd17c352f, scale 1 only, plain fp32 window sums) the flag moved it from 1.79e-7 to 1.19e-7 on the Netflix pair. speed_chroma's six differing outputs are the CPU's glibc log2f (ADR-1380), not the twin.

Against the ADR-0214 tolerances (FEATURE_TOLERANCE in scripts/ci/cross_backend_parity_gate.py; the gate runs the Netflix pair): every twin is inside its tolerance on the Netflix pair before and after. Run as the gate itself (--backends cpu cuda): all 18 cells pass before and after (adm, cambi, ciede, float_adm, float_moment, float_motion, float_ms_ssim, float_ms_ssim_lcs, float_psnr, float_ssim, float_ssim_lcs, float_vif, motion, motion_v2, psnr, psnr_hvs, ssimulacra2, vif). One is outside it on larger frames, before and after alike, for a reason the flag does not touch: float_motion on the checkerboards (1.36e-4 against 5e-5; finding 4).

3. float_ms_ssim_cuda relied on contraction in two ways; with the reference's arithmetic it is bit-identical¶

With the flag alone the twin gets closer on small frames and further at 4K. The steps, each on top of the previous (max / mean absolute difference):

What differed from the CPU, in the order the steps remove it:

1. ms_ssim_decimate.c accumulates each low-pass tap with one fused multiply-add (vmaf_fmaf_exact(), fmadd in the SIMD twins). The kernel wrote acc += sample * tap and matched only because nvcc fused it.
2. iqa_convolve() forms each Gaussian-window product in fp32 and adds the products in fp64, then rounds to fp32 once per pass. The kernel kept an fp32 running sum. Fusing each step, which keeps the product exact, hid most of the difference; without fusion it shows, most at 4K.
3. ssim_accumulate_default_scalar() divides an fp64 numerator by an fp32 denominator for l and c, and computes s as an fp32 quotient; its constants C1, C2, C3 are fp32. The kernel promoted all of it to fp64.
4. iqa_ssim() returns each per-scale mean as a float and ms_ssim.c raises the floats to the Wang exponents. The host kept fp64 means, so the 15 enable_lcs outputs were up to 1.3e-6 off as well.

The fp64 window sums cost 3.4 ms per 3840x2160 frame: 10.73 -> 14.09 ms (7 alternating repetitions of 100 frames; 10.49 -> 14.44 with 5 repetitions of 20 frames). An fp32 pair (running sum plus the exact error of each addition, six fp32 operations per term) carries the 11-term sum to about 48 bits, gives the same 104 frame scores, and costs nothing measurable (10.54 -> 10.57, 7 repetitions of 100 frames). It is what ships. It is not the reference's operation literally: the pair and the 53-bit sum can round to different fp32 values when the exact sum lies within about 2^-18 ulp of a rounding boundary, which then moves one pixel's statistic by one ulp. The fp64 l / c / s block sums differ from the CPU's raster order by more than that already; the fp32 rounding of the mean absorbs both.

4. What the remaining differences are¶

• float_motion: the CPU keeps one fp32 running sum of the absolute differences of a whole plane (float_sad_line_c() per row, compute_motion_simd() over the rows) and divides in fp32. The kernel sums per 16x16 block and the host adds the blocks in fp64. Replayed on the host for the 1920x1080 checkerboard: blur and differences in fp32 with separate multiply and add, then the fp32 running sum, reproduces the CPU's score bit for bit (18.805618286132812 and 18.8588924407959 for frames 1 and 2); the fp64 sum of the same differences is 1.17e-4 and 1.35e-4 lower, and the twin is within 6e-7 of that. So the blur matches and the whole gap is the CPU's own rounding. T-CUDA-FLOAT-MOTION-CPU-FLOAT-SUM-2026-10-01.
• float_vif: not isolated. The kernel calls the device log2f where the CPU calls glibc's on an fp64-promoted argument, and it reduces per block. The SYCL twin shows the same two numbers on the Netflix pair before and after ADR-1367 (2.71e-5 and 3.81e-5), so contraction-free CUDA and SYCL now agree with each other. T-CUDA-FLOAT-VIF-RESIDUAL-2026-10-01.
• ciede: per-pixel pow, sqrt, sin, atan2 on the device against libm; tolerance 5e-3.

5. Cost¶

3840x2160, BBB, one twin per run, (t(N) - t(2)) / (N - 2) ms per frame, alternating pairs with the order swapped every pair; median before and after, then the median and the quartiles of the paired difference. The host is shared; twins whose machine code is identical show what it resolves.

15 pairs, N = 102, load average 9 to 16:

The two largest, repeated with 21 pairs and N = 200, load average 9:

No paired difference is distinguishable from the controls; the other thirteen twins run the same code as before. At 4K these twins spend their time reading and uploading the frame, not in the kernels (what the flag adds to float_motion, about 70 separate multiplies and adds per pixel, is a few microseconds per 4K frame on this GPU). A kernel-only measurement needs a quiet host or an in-process harness; vmaf_bench --gpu-profile is SYCL-only.

6. The clang CUDA path¶

-Denable_nvcc=false did not configure on master: the shared fatbin command concatenates nvcc_ccbin_flags and nvcc_host_includes, which only the nvcc branch assigned. With both assigned (empty) and -ffp-contract=off, clang 22.1.8 builds all 21 kernels against CUDA 13.4 (it warns that the SDK is newer than it knows). Its PTX has mul.rn.f32 / add.rn.f32 throughout and fma.rn.f32 only where the source asks for it.

Run on the RTX 4090 against the nvcc build of the same tree, on the four fixtures (BBB: 22 frames): 18 of the 19 twins give the nvcc build's value on every output of every frame (3 952 outputs), among them the ones that are not bit-identical to the CPU (adm, float_adm, float_vif, float_motion, ssim, ssimulacra2, speed_chroma); float_ssim and float_ms_ssim are bit-identical to the CPU under both compilers. The one that differs calls device math functions: ciede (6 of 76 outputs equal, 1.13e-5 from the CPU against nvcc's 1.14e-5). The first clang build of float_ms_ssim_cuda matched the CPU on 9 of 48 frames (3.4e-8): clang compiles sqrtf() to sqrt.approx.f32 where nvcc emits sqrt.rn.f32. With __fsqrt_rn() the clang build is bit-identical to the CPU on all 104 frames as well, and the nvcc machine code is unchanged.

Reproduce¶

meson setup build-cuda core -Denable_cuda=true -Denable_sycl=false --buildtype=release -Db_lto=false
ninja -C build-cuda
# which fatbins hold FMAs
for f in build-cuda/src/*.fatbin; do printf '%s %s\n' "$f" "$(cuobjdump -sass -arch sm_89 "$f" | grep -c FFMA)"; done
# one twin against the CPU
python3 scripts/dev/speed_gpu_parity.py --backend cuda --vmaf "$PWD/build-cuda/tools/vmaf" \
  --netflix-dir python/test/resource/yuv --bbb-dir testdata/bbb --feature float_ms_ssim
build-cuda/test/test_cuda_float_ms_ssim_parity
python3 -m pytest core/test/test_strict_fp_compiler_args.py core/test/test_cuda_kernel_source_contract.py