Research-1437: Which HIP twins return the CPU extractor's bits — a sweep of every gate feature on a gfx1036¶

• Status: Active
• Workstream: ADR-1437, ADR-1421
• Last updated: 2026-10-01

Question¶

RC3 asks every GPU twin to return the CPU extractor's bits, or to differ only by the math library with a derived bound (ADR-1421). On HIP three twins were declared exact (adm, float_motion, psnr_hvs). For the others: which already return the CPU's bits, on which inputs, and how far are the rest?

Sources¶

• origin/master 80c5a0332, HIP-only release build (-Denable_hip=true -Denable_hipcc=true -Dhip_gfx_targets=gfx1036 -Db_lto=false), gcc 16.2.1, ROCm 7.2.4, AMD gfx1036 (the integrated GPU of a Ryzen 9 9950X3D), Linux 7.2.8-1-cachyos, 2026-10-01. Other sessions shared the host.
• Every key of FEATURE_METRICS in scripts/ci/cross_backend_parity_gate.py (20 features, all with a HIP twin), run through that gate's command builder with --precision max, --backend cpu against --backend hip with the twin named, and its frame diff with tolerance 0 over every output both sides emit, not only the outputs the gate lists.
• Fixtures of the first table: the Netflix 576x324 pair at 8 bits (48 frames) and 10 bits (3), the two 1920x1080 checkerboard pairs (3 each), Sparks 480x270 at 10 bits (5), and the first 48 frames of BBB 3840x2160.
• Fixtures of the second table: the Netflix pair at 12 and 16 bits (3 frames each) and as 10-bit 4:2:2 (48), two frames of independent full-range noise at 576x324 and 8, 10, 12 and 16 bits (3 frames each), and a bright 16-bit 1920x1080 pair (samples 56000 to 64000, 2 frames). The noise and the bright pair were generated for this sweep to reach the cases real content does not: large differences in every block, and sums of large squares.
• A cell that differed was run twice more. Every such cell returned the same values in all three runs, so each difference below is arithmetic. No run of the sweep showed the device's lost stream commands (T-HIP-GFX1036-DROPPED-DISPATCHES-2026-10-01): 511 HIP runs.

Findings¶

Frames whose HIP output equals the CPU's, typical content¶

Cells are identical frames / frames.

adm_hip emits no integer_adm3 / integer_aim (T-GPU-ADM-AIM-DEVICE-PASS-MISSING-SYCL-HIP-2026-09-05).

High bit depths, 4:2:2 and stress content¶

psnr_hvs refuses 16-bit input on the CPU and on the twin.

What each result is¶

The caveat on float_ms_ssim¶

ssim_accumulate_default_scalar() adds l, c and s of every window into three doubles, in raster order, and iqa_ssim() returns each mean as a float. The HIP twin (and the SYCL twin, ADR-1414) adds the same per-window values in another order and rounds the mean to float the same way. Two double sums of the same N terms in different orders differ by rounding of the order of sqrt(N) * 2^-53 of their value (the random-walk estimate), about 3e-13 for the 8.3 million windows of a 3840x2160 scale; the mean's float rounding has a step of 6e-8 to 1.2e-7 of it. The two round to different floats only when the sum lies that close to a rounding boundary: by this estimate a few means in a million. It is an estimate, not a measurement. The CPU's own AVX2 and AVX-512 accumulators add in yet another order and rely on the same rounding. No mean differed on the 178 frames here (2848 values), nor on the 107 frames of ADR-1403.

Method notes¶

• The gate's own listing was not enough: psnr lists psnr_y only, and the twins emit more. The sweep compares every output both sides emit and reports an output only one side has.
• The repository's 10-, 12- and 16-bit Netflix fixtures are the 8-bit clip shifted left: every sample has zero low bits. They exercise no arithmetic an 8-bit frame does not, which is why they agree wherever the 8-bit pair agrees.
• 8-bit natural content does not separate "exact by construction" from "exact on this input". The noise frames and the 16-bit frames did: float_psnr_hip and float_moment_hip are identical on all 110 frames of the first table and are not exact twins.

Open questions¶

• Why float_adm_hip differs, per stage.
• Whether ssimulacra2_hip can round its sums as the CPU's sequential sums do (the CUDA twin does since ADR-1433, at twice the frame time) at a cost that is acceptable on this device.