REPROGPU: Cross-Adapter Bit-Reproducible WebGPU Kernels and a Conformance Harness for a Declared Integer Subset

A GPU result is not a portable number. The WGSL CRD of 2026-09-15 specifies floating-point arithmetic only loosely: section 15.7.4.1 gives x+y, x-y, and x*y as correctly rounded to either neighbour with the rounding direction unspecified, gives x/y as 2.5 ULP rather than correctly rounded, permits reassociation and fusion in section 15.7.5, permits subnormal flushing and an indeterminate value for runtime overflow and NaN in section 15.7.2, and says the sign of zero may be ignored. Two drivers on the same machine may therefore return different bits for the same shader, and two vendors need not agree at all. This is not a defect in a particular engine; it is the specification's declared boundary. NVIDIA's own reproducibility team states that bit-exactness is not expected across GPU architectures (framework-reproducibility issue #28), and the WebGPU CTS tests floating-point accuracy within ULP tolerances rather than bit-exact cross-adapter equality.

The consequence is that a browser GPU computation cannot currently be re-run and compared by a third party. Scientific reproduction of a GPU-assisted result, verifiable browser compute, and automated grading of a computational answer all need the same missing property: the same declared program on a different adapter either produces the same bytes or is reported as a divergence. The smaller observation, and the one this paper builds on, is that a well-defined subset of WGSL already has that property. Integer wrapping arithmetic, bitwise operations, comparisons, bitcast between i32 and u32, and the little-endian host-shared buffer layout are all specified exactly. If every real step of a kernel is reduced to those operations, then the output bytes are a function of the input bytes alone, independent of adapter, workgroup schedule, or compiler reassociation. The hard part stops being the arithmetic and becomes the discipline of staying inside the subset, pinning the source bytes, and building a harness that can tell a genuine divergence from a partial or stale run.

• A declared integer subset with a written boundary: only i32/u32 arithmetic, bitwise operations, comparisons, bitcast between i32/u32, and host-shared little-endian layout are relied upon; all f32 values are transported and decoded as opaque u32 bit patterns, and no float arithmetic, conversion, or bitcast through float occurs in K1 to K4.
• Five kernels: K1 exact f32 summation by a 10-limb (320-bit) integer superaccumulator; K2 Philox4x32-10 counter RNG against published Random123 vectors; K3 Q16.16 256x256x256 GEMM with a 3-limb (96-bit) accumulator and a single arithmetic floor shift; K4 integer SHA-256 over a fixed 1 MiB message; and K5, an f32 matmul negative control that carries no pass criterion, no pinned hash, and no recorded outcome in this artifact.
• A CPU-only permanent gate that reproduces every pinned reference hash and count, runs the known-answer tests, pins the WGSL source bytes, and scans the integer kernels for float types, atomics, discard, and unmasked dynamic shifts.
• A cross-adapter manifest spec: per-record adapter identity, dispatch shape, output bytes and raw-byte SHA-256, status count and flags, compile errors, and outcome, serialized canonically and hashed.
• An explicit negative control and an explicit honesty rule: K5 is an f32 matmul with no pass criterion, no pinned hash, and no recorded outcome in this artifact; the gate checks references and vectors, the browser lab is the demonstration, and no CI artifact may be cited as evidence of GPU agreement.
• A limitations list that names non-finite inputs, out-of-range wrap, the one-machine sample, self-reported adapter identity, machine-checkable exceptions, the absence of any recorded cross-adapter comparison, and the non-claim about general float.

The adversarial prior-art search returned GO-WEAK, and the verdict is taken as given. The headline capability - making a documented subset of GPU compute bit-reproducible across vendors - is a mature, named category. ReproBLAS defines the binned accumulator for order-independent float summation; ExBLAS combines floating-point expansions with a Kulisch superaccumulator and already reports bit-perfect reductions and GEMM on NVIDIA and AMD GPUs; the Ozaki scheme decomposes GEMM into error-free integer and modular pieces and runs on Tensor Cores; and NVIDIA's own CCCL ships a reproducible floating-point accumulator that makes gpu_to_gpu reductions identical across different NVIDIA GPUs. Counter-based RNG is a 2011 design already in cuRAND, rocRAND, and NumPy; deterministic training and inference is covered by RepDL and Hawkeye; reproducible BLAS on CPUs is oneMKL's conditional numerical reproducibility; and the WebGPU CTS is already a cross-vendor, normative test suite. None of that is new here, and no row of T1 is a strawman.

The remaining clause is narrow and is a delivery delta rather than a scientific one: no located project pins cross-adapter (vendor-to-vendor) byte-identical output hashes for a declared integer and fixed-point WGSL kernel set and ships the reusable harness and manifest that produce them. The exact integer-execution idea itself is already demonstrated in a browser: the Coherence Energy Labs gpu-exact demo runs one fixed-point kernel on the CPU and a WebGPU i32 shader on the GPU and shows the same SHA-256, with the same integer-exact/float-drifts scope note this paper draws; bitgpu ships bit-exact browser WebGPU integer execution, though as an application runtime rather than a conformance protocol. What is not located is the multi-kernel, pinned-reference-hash, cross-adapter manifest protocol around that idea. The WebGPU CTS tests accuracy within tolerances, not bit-exactness; the zkML line proves properties of a computation rather than reproducing its exact bytes; and the PAradigm brief that recommends exactly this integer-only-core-plus-conformance-matrix design is a research note with no code and no hashes. T1 states the delta row by row, including the motivating counter-pressure that bit-exactness across GPU architectures is not the norm. Every URL in T1 was read by the prior-art pass on the dates recorded there; a change to a cited URL or a cited WGSL section number invalidates the corresponding statement and must be re-checked.

Correction to the prior-art record. The first prior-art pass for this wave did not locate the Coherence Energy Labs gpu-exact demo or bitgpu, and an earlier draft of the abstract and of this section described the capability as unmatched without them; both were added after publication and are now rows in T1. With them, the honest description of the contribution is a narrow systems/artifact package - a declared exactness boundary, a multi-kernel suite with pinned reference hashes, a cross-adapter manifest, and a gate that publishes what it cannot prove - on top of an idea (exact integer execution, hashed and compared) that is already demonstrated elsewhere. The correction is recorded in docs/research/wave-48-priorart-reprogpu.md rather than silently patched.

The subset is chosen from the specification, not from benchmarking. The following are guaranteed portable and exact, and the kernels are built only from them. Expressions on concrete integer types that overflow produce a result modulo 2^bitwidth (section 6.2.3), and i32 is two's complement, so i32 and u32 addition, subtraction, multiplication, and unary negation all wrap exactly. Bitwise and, or, xor, and complement are exact and component-wise (section 8.10). Comparisons and select are exact (section 8.9). Shifts are specified as the shift value modulo the bit width of the left operand, so u32 right shift is logical and i32 right shift is arithmetic (section 8.10). Bitcast between i32 and u32, and between their vectors, is an exact bit reinterpretation (section 17.2.1 with layout in section 14.4.4). Numeric values in host-shared buffers are stored little-endian (section 14.4.4), so readback can be byte-addressed.

The following are excluded because the specification leaves them implementation-defined. All f32 and f16 arithmetic is out, because section 15.7.4.1 gives the rounding direction as either neighbour for add, subtract, and multiply, because division is 2.5 ULP rather than correctly rounded, and because section 15.7.5 explicitly permits reassociation and fusion, so a*b+c may or may not contract to fma and fma itself may expand. Subnormal inputs and outputs may be flushed to zero, the sign of zero may be ignored, and runtime overflow, infinity, and NaN may become an indeterminate value (section 15.7.2, the Finite Math Assumption). Transcendentals, determinant, smoothstep edges, and out-of-bounds indexing are likewise excluded. Mapping a floating-point value to an integer is also not exact (section 15.7.6), so K1 never converts an f32 value; it only decodes its bit pattern as u32.

Declared boundary. Only integer (i32/u32) and bit operations, bitcast between i32/u32, comparisons, and host-shared buffer layout are relied upon. In K1–K4 all f32 values are transported and decoded as opaque u32 bit patterns; no floating-point arithmetic, conversion, or bitcast-through-float occurs. All floating-point results are out of scope for the reproducibility guarantee.

Every kernel follows the same discipline. It reads only u32 or i32 words, performs only exact operations, and writes a status word first. Multi-limb integer addition is associative and exact on bounded values, so any workgroup schedule produces identical limbs; this is a proof, not an empirical result, and the fixed reduction tree is pinned anyway so that the byte serialization is recomputable without depending on a schedule. No kernel uses discard, an unmasked dynamic shift count, a floating-point operation, or atomic. Every input buffer is pre-filled with the sentinel 0xDEADBEEF and every output begins with a count canary, so a partial run or a stale buffer is detectable rather than silently hashed. The five kernels and their pinned reference outputs are below.

term = (-1)^s * M * 2^shift, with M = m for a subnormal (shift = 0) and M = 0x800000 | m for a normal (shift = e - 1); let b = shift mod 32 and L = floor(shift / 32); if b == 0 add M at limb L, otherwise add (M << b) & 0xFFFFFFFF at limb L and M >> (32 - b) at limb L + 1; the accumulator is A[0..9] with value sum over i of A[i] * 2^(32i), and a negative term is negated by inverting all ten limbs and adding one with a carry from limb 0. Terms and partials are then added with carries propagated from limb 0 to limb 9.

S = sum over k of u32(A[i,k]) * u32(B[k,j]) mod 2^96, accumulated exactly as a 3-limb two's-complement value; result32 = (S arithmetic-right-shift 16) & 0xFFFFFFFF; the stored i32 is the low 32 bits and wraps modulo 2^32 when the floored value leaves the i32 range (section 6.2.3). The k loop is fixed at k = 0..255 and the accumulator is 96 bits because |product| < 2^62 and |S| < 2^70.

The harness runs each kernel on each available adapter, reads the output buffer back, hashes the raw bytes, and emits a manifest. Its per-record fields are fixed: kernel, kernelVersion, wgslSha256, adapter identity (vendor, architecture, device, description, features, and a subset of limits), dispatch shape, output byte length, output SHA-256, status count and flags, duration, timestamp, user agent, compile errors, and an outcome of pass, fail, exception, or skip. The source hash is shared: all adapters run the same module bytes, the manifest records wgslSha256 once per kernel, and the gate pins it.

export interface ManifestRecord {
  kernel: KernelId;                 // K1 | K2 | K3 | K4 | K5
  kernelVersion: number;
  wgslSha256: string;               // SHA-256 of the module bytes, CRLF -> LF
  adapter: AdapterInfo;             // vendor, architecture, device, description, features, limits
  dispatch: { workgroups: number[]; workgroupSize: number[] };
  outputBytes: number;
  outputSha256: string;             // SHA-256 of the raw readback bytes
  status: { count: number; flags: number };
  durationMs: number;
  timestampISO: string;
  userAgent: string;
  compileErrors: string[];
  outcome: "pass" | "fail" | "exception" | "skip";
}

// Canonical manifest JSON: UTF-8, keys sorted, arrays sorted by kernel then
// adapterKey (vendor|architecture|device|description), no insignificant
// whitespace; manifestSha256 = SHA-256(serialized manifest) is included in the
// artifact and re-derived by the gate.

Readback is byte-exact by construction: copyBufferToBuffer, then mapAsync in read mode, then copy to a fresh Uint8Array and unmap, and hash the raw bytes rather than a typed-array numeric view, because a Uint32Array view would make the hash depend on host endianness. The sentinel and canary rules close the silent-no-run hole: every input buffer is pre-filled with 0xDEADBEEF, every output begins with a count word, the harness rejects a kernel whose output equals the sentinel or whose count differs from the pinned expected count, createShaderModule is followed by a compilation-info check that must report zero errors, validation and out-of-memory error scopes are pushed, and onSubmittedWorkDone is awaited. A mismatch that matches a pre-declared entry of exceptions.json becomes an exception with the adapter identity, kernel, observed and expected hash, reason, and an evidence URL; anything else is a fail. A compile or limit failure is a skip with the reason recorded, and if every GPU skips, the demonstration is empty and the paper must say so.

The pass rule for K1 to K4 is exact: every non-skipped record passes if and only if outputSha256 equals the pinned expected hash for that kernel, the status count equals the pinned expected count, and compileErrors is empty. K5, the float negative control, has no pass criterion at all. Its per-adapter hash is recorded, a second dispatch gives a run-to-run measurement, and the run is classified as divergent, run-to-run only, or agreeing. If every adapter agrees, that is recorded as an observation about that hardware set and this one time, with no generalization to floating point. The gate checks none of this, because it has no GPU, and no K5 record is committed to this repository: a reader who runs the lab is the first to observe it, which is why the abstract and the claim ceiling describe K5 as a control rather than as a demonstration.

The experiments here are deterministic and CPU-only. They establish the reference side of the claim: that the shipped TypeScript references reproduce the pinned hashes and counts, that the integer implementations match external known-answer tests, that the WGSL source bytes are pinned, and that the integer kernels stay inside the declared subset. The cross-adapter side is not an experiment in this paper; it is the browser lab of section 8, and the only honest statement about it is that a local manifest is a small, time-stamped, self-reported sample. The gate runs in about one second on the authoring machine, and every number in T3, T4, and T5 is re-derived on each run with no auto-update path.

What the known-answer tests do and do not buy. The three Philox lines and the two FIPS SHA-256 lines are external oracles: they were not produced by this codebase, so agreement is evidence that the integer algorithms are the standard ones rather than that the pins are self-consistent. The K4 message digest is checked against a Node/Web Crypto SHA-256 oracle on the exact 1 MiB LCG message in the test suite. The K1 reference is an exact BigInt reconstruction; the K3 reference is compared against a naive O(n^3) BigInt implementation on small seeded sizes in the test suite. The pins themselves are regression anchors: the same reference computes both the expected constant and the observed value, so a pin can only catch drift, and correctness rests on the external oracles and on the exactness argument, not on the pin.

The limitations below are the amended spec's, quoted verbatim. Each names a real envelope of the shipped system or of the experiment, not a caveat added after the fact.

1. The guarantee covers only K1–K4 and only the shapes/domains declared above; float is out of scope (WGSL CRD 2026-09-15 §15.7.2/§15.7.4/§15.7.5).
2. The gate verifies the references, KATs, pins, and source integrity; it cannot execute WGSL or test cross-adapter equality. The browser lab is the demonstration, not the CI gate.
3. Cross-adapter results are a small, time-stamped sample on one machine; adapter.info is self-reported and not cryptographically attested; engine support is limited and may change.
4. K1 excludes non-finite inputs (flagged and rejected); K3 documents mod-2^32 wrap on out-of-range output, which is a design ceiling rather than something the shipped seeded vector exercises; none of K1–K4 covers general float.
5. Any adapter mismatch is a fail unless it is a pre-declared, reproducible exceptions.json driver bug; exceptions are reported, not hidden.
6. K5 divergence is permitted and K5 agreement is possible; neither outcome is recorded in this artifact, and K5 agreement on any hardware set is not evidence of general float reproducibility.

The product is a single browser page at /reprogpu. It requests a WebGPU adapter, renders an adapter card with the self-reported vendor, architecture, device, and description, and lets the reader run the five kernels. For K1 to K4 the page shows the pinned expected hash next to the live output hash and the status count next to the expected count, so a reader sees pass or fail directly rather than a summary. For K5 the page shows the per-adapter hash and the second-dispatch comparison, classified as divergent, run-to-run only, or agreeing, with copy that says agreement is an observation and not a reproducibility claim. The run produces the full manifest of section 5, which the reader can copy or download; the page re-derives manifestSha256 so a third party can compare it against the committed artifact. The run is local: inputs never leave the device and only output hashes are publishable.