wai-quantum: the state vector resident on the GPU, auto placed by committed measurements, Pauli propagation on CUDA, an aarch64 board measured and in CI #558

Merged

dcharlot merged 10 commits from wai/quantum-gpu-resident into main 2026-11-01 01:56:12 -04:00

Conversation 0 Commits 10 Files changed 43 +9567 -660

2026-10-31

Transaction Science

wai-quantum quantum_spd: expectation_table compiled only where it is called ...

Only the device reference (under `quantum_fabric`) and the host test read
the table. The pulse, error-correction and variational workflows check the
library on `quantum_engine` and the sets beside it under `-D warnings`,
where the function was dead and failed the build.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

d4cdbb7da2

• View at this point in history

2026-10-31 23:29:40 -04:00

Transaction Science

wai-quantum: the aarch64 board measured again, by CUDA and by OpenCL ...

engine::fabric_measured's rows for the board are replaced by one pass over
both its GPU members, the way the other hosts were measured: 36 rows taken
with examples/fabric_timing.rs on 2026-10-31, now that the board has an
OpenCL driver (PoCL 7.2, whose CUDA device runs PTX for sm_90). From 22
qubits the OpenCL member's times are within 1.2% of the CUDA one's; at 20
qubits it is 21 to 36% quicker than CUDA. Both won some rows below 24
qubits and lost every row from 26 qubits at every fusion width (28 qubits,
fusion 3: 22.5 s on the CPU against 27.7 s by either), so no size has a
faster tail there and auto still keeps the board's states on the CPU. From
22 qubits the CUDA rows repeat the first pass's to within 2.5% (the GPU's
own times to within 0.5%). Discovering both members takes 2.6 s. The host
entry, the module notes, the README (en, zh-CN) and the changelog say so.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

cd7e5068d8

• View at this point in history

2026-10-31 22:05:01 -04:00

Transaction Science

wai-quantum CI: the WebGPU hardware job on the aarch64 board too (linux-arm64-hw) ...

member-hw is now a matrix over the two hosts with GPUs, the way the CUDA
and OpenCL hardware jobs are. Each host's adapters are declared in the
workflow: jetson-hub's discrete and integrated GPUs and the software
Vulkan driver (the set its runner declared until now), and the board's
GPU and the software Vulkan driver. Both steps ran on the board first:
the member's 14 tests, the wide sizes to 26 qubits on its GPU, and the
conformance corpus through the member.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

c2e04bcdf9

• View at this point in history

2026-10-31 22:05:01 -04:00

Transaction Science

wai-quantum CI: the CUDA and OpenCL hardware jobs on a second host, an aarch64 board (linux-arm64-hw) ...

cuda-hw and opencl-hw become matrices over the hosts with such devices. Each entry declares the
host's devices in the repository: its CUDA GPU, the fabric's members there and one state split
over them (cuda-hw), and its OpenCL devices (opencl-hw), sorted as discovery names them.
- jetson-hub (linux-hw), as before: gpu-cuda-sm89; fabric gpu-cuda-sm89, opencl-cpu-8086 and
  opencl-gpu-10de; OpenCL opencl-cpu-8086, opencl-gpu-10de and opencl-gpu-8086 (its integrated GPU,
  whose state vector is refused for want of binary64). Its jobs keep their names.
- thor (linux-arm64-hw), new: gpu-cuda-sm110 (compute capability 11.0, CUDA 13.2); fabric
  gpu-cuda-sm110, opencl-cpu-13b5 and opencl-gpu-10de; OpenCL through PoCL 7.2, for its CPU and,
  through CUDA, its GPU, with POCL_CUDA_GPU_ARCH=sm_90 (PoCL's LLVM 18 has no sm_110; the driver
  compiles the PTX for the GPU).
The one step line that named jetson-hub's CUDA key takes the declared one.

Every step of both jobs ran on thor before this: the CUDA member's 4 certificates, the tensor-core
kernel's 4, the state vector's pinned 48 and 120 cases, 140 random resident runs, 4 of 4 mutants,
Pauli propagation's certificate and large sums; the OpenCL members' 4 certificates each, their
state vectors' 48 and 120 cases and 140 random runs; and the fabric's 7 placement tests, one state
split over the CUDA GPU, PoCL's GPU, PoCL's CPU and the CPU reference giving the CPU's answers byte
for byte.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

814abd69cf

• View at this point in history

2026-10-31 22:05:01 -04:00

Transaction Science

wai-quantum OpenCL member: the state zeroed by a 4-byte pattern, and PoCL's GPU launched at a size it can take ...

Two things PoCL's CUDA device does not do, each of which ended the process rather than returning
an error, found certifying it on an aarch64 board:
- a fill of 8 bytes or more (pocl-cuda.c: "fill_kernel with pattern_size >=8 is unimplemented"),
  which the resident state vector used to zero its arrays with 0.0. A fill of a 4-byte zero gives
  the same bits and every runtime takes it, so the arrays are zeroed so on every device;
- a launch of the wider kernels at the work-group size it chooses itself
  (CUDA_ERROR_LAUNCH_OUT_OF_RESOURCES). On PoCL's GPU devices alone, each launch now names the
  largest power of two the kernel takes there (CL_KERNEL_WORK_GROUP_SIZE), at most 128, with the
  global size rounded up to a multiple of it; the kernels stride, so the items past the work do
  nothing. Every other runtime still chooses its own, so their measured timings stand.

On the board, PoCL 7.2 (LLVM 18) on its CPU (opencl-cpu-13b5) and on its GPU through CUDA
(opencl-gpu-10de) then certify bit-exact on every kernel: the lanes kernels, the state vector's
48 cases (b7d129d0) and its 120 wide cases (093614f2), 4 of 4 mutants caught, and 140 random
resident runs the CPU's bit for bit. The laptop's OpenCL members certify as before with the
change: its GPU bit-exact on both, its CPU's wide kernels not bit-exact, its integrated GPU
refused for want of binary64.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

36819bf439

• View at this point in history

2026-10-31 22:05:00 -04:00

Transaction Science

wai-quantum: the measurements on a third host, an aarch64 board whose GPU loses from 26 qubits ...

engine::fabric_measured gains a host and its 18 rows, taken with examples/fabric_timing.rs on
2026-10-31: 14 aarch64 cores sharing 122 GiB with an integrated GPU of compute capability 11.0, by
CUDA. The GPU won some rows below 24 qubits and lost every row from 26 qubits at fusion 3, 2 and 1
(28 qubits, fusion 3: 22.6 s on the CPU against 27.7 s), so no size has a faster tail there and auto
keeps that host's states on the CPU. The README (en, zh-CN) and the changelog say so.

The same board ran the CUDA hardware job's steps: the member found as gpu-cuda-sm110 on CUDA 13.2,
every certificate bit-exact with the pinned digests the x86-64 laptop's GPU gives.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

99c96cd789

• View at this point in history

2026-10-31 22:05:00 -04:00

Transaction Science

wai-quantum views: the page rebuilt with the engine the resident state vector and GPU Pauli propagation changed, in the image CI rebuilds it in ...

Rebuilt with wai/wai-quantum-views/build.sh in catthehacker/ubuntu:act-22.04 with Rust 1.98.0, as
the views workflow rebuilds it.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

cc08f85a0c

• View at this point in history

2026-10-31 22:05:00 -04:00

Transaction Science

wai-quantum: sparse Pauli dynamics on the GPU, with the CPU's term set, order and bits ...

The propagation's sum of terms can now live on a device (quantum_spd::device).
The device runs each step's arithmetic on every term at once: one multiply by
sin, one by cos, one addition where a new term meets an old one, and sign
changes, built without fused multiply-add. The host keeps everything that
decides the term set. A rotation's new terms are found in the table, dead
slots included, and the rest are appended in the order of the terms they came
from by an order-preserving prefix sum. The host counts dead and live terms
and compacts exactly when the CPU does. A truncation hands back the
magnitudes it dropped in table order, and the bound and the value are added
on the host in table order (expectation_on over an SpdDevice).

Ground truth first: HostDevice runs that protocol on the CPU, one term after
another, and is the CPU's propagation bit for bit, final table included, over
100 cases at one thread and many. The CUDA member (CudaSpd; kernels
quantum_fabric::spd, implementation cuda-spd) is certified on SPD_DEFAULT
against the CPU. The corpus is 40 cases on one to four words, with term and
weight caps, layered circuits whose dropped strings come back and are revived
in place, and one exact cancellation. Each case's output is every value,
bound, threshold reached and count, and the final table slot for slot, so a
device that keeps the numbers but not the term set or its order is caught: a
mutant that appended a revived string again survived a corpus of numbers
alone. All six mutants are killed. On the laptop GPU: certified, and 24
wider random cases up to two million terms and the 127-qubit kicked-Ising
circuit are the CPU's results bit for bit.

A pauli job asks with fabric (accelerator, or a member's id or key): its sum
of terms runs on that member, with the CPU's answers byte for byte, and the
result's fabric names the member and its certificate (kernel
wai.quantum.spd/propagate). cpu names the CPU, and a split is refused (J013).
auto keeps the method on the CPU, since no member is measured faster for it.
Its members are discovered apart from the state vector's, and wai-quantum
fabric lists them (pauli, optional, in the tools schema). The CUDA leg
certifies the propagation and kills its mutants; the placement legs run a
pauli job on each member, or see accelerator refused; the container legs
name the protocol's tests. Docs, help, both MCP servers' descriptions, the
guide and the changelog say so; agent docs re-blessed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

bc2ee2f516

• View at this point in history

2026-10-31 22:05:00 -04:00

Transaction Science

wai-quantum: auto places a state on a member only where the measurements say it is faster ...

The resident state vector was timed against the CPU as whole jobs of one
circuit family (ten layers of arbitrary-angle rotations and brickwork
entangling pairs, 1000 shots): five runs of each, alternating, at fusion 3, 2
and 1, from 18 qubits to as many as half the host's memory held, on two hosts
on 2026-10-30. The rows, each host's load, and what discovering its members
took are committed (engine::fabric_measured), and examples/fabric_timing.rs
takes them again.

A row is faster when every run on the member beat every run on the CPU. auto
places a state on a member from the smallest measured size from which every
row up to the largest is faster, up to that largest, at the fusion width
measured, for a plan of at least the measured launches; a process that has not
discovered its members yet does so only where the saving also covers that
discovery. Hosts are named by fabric::host (the processor's model,
architecture and threads, hashed), members by id, so another processor,
device or driver matches nothing and stays on the CPU.

What the rows say: the laptop GPU is never faster from 22 qubits up at any
fusion width (26 qubits at fusion 3: 3.74 s on the CPU, 4.44 s by CUDA, 4.29 s
by OpenCL), so auto keeps every state on that CPU. The integrated GPU beat its
CPU in every run at fusion 3 and 2 from 18 to 28 qubits (22 qubits: 205 ms
against 108 ms by HIP and 102 ms by OpenCL; 28: 9.81 s against 8.47 s and
8.14 s) and lost from 22 qubits at fusion 1, so auto places fused jobs there,
from 18 qubits once the members are discovered and at 28 in a fresh process
(discovery takes 1.2 s). A member auto chose that fails during the run hands
the job back to the CPU.

A job auto placed carries the rule, the host, the day, the load and the
measured row it rests on in its receipt (fabric.auto, with fabric_spread), and
the plan's reasons say so; wai-quantum fabric prints the rule, where it places
here and every measured row (auto_rule). Docs, help, both MCP servers'
descriptions, the guide and the changelog say so; agent docs re-blessed. The
placement legs hold auto to the measurements on each host.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

fa578e06cd

• View at this point in history

2026-10-31 22:05:00 -04:00

Transaction Science

wai-quantum: the state vector resident on the device, its wider kernels certified on their own ...

A member now runs a whole plan with the state on the device (sv64 host
layout 2): the state is zeroed there, or uploaded once for a partition, every
launch's parameters go up once as a LaunchTable, each launch is enqueued in the
CPU's order on one stream or in-order queue with no wait between them, and
the state comes back once, on CUDA through two page-locked buffers in turn.
The formulas are the same; a gate on two to five qubits takes a kernel
compiled for its group size, its group in registers. The host layout is part
of every implementation id, so each certificate is of the resident path.
Splitting is unchanged: exchanges are its only host round trips. CudaSv,
HipSv and OpenClSv gain run_from_zero, and max_qubits follows the device's
memory (at most 32) rather than the dyadic core's 26.

Ground truth first: the uploaded table decodes to the plan and replays to the
CPU's state; on each device random circuits at fusion 0 to 6, from |0...0> and
from a given state, are the CPU's bit for bit. That test caught one CPU's
OpenCL runtime reordering the five-qubit kernel's sums on about one input in
six, which the pinned corpus (fusion 0, 2 and 3) never reaches. So the wider
kernels (gates on more than three qubits at once) are certified on a corpus of
their own, SV_WIDE (120 cases at fusion 4 to 6, pinned; 36 cases let the fault
through), and a member is placed for such a job only where they certified
bit-exact; elsewhere it is refused (J013) and accelerator passes over it. The
receipt carries the member's wide certificate when the job used those kernels
(fabric_wide, optional, in the job-result and tools schemas).

On the fleet: the laptop GPU by CUDA and OpenCL, the CPU beside it by OpenCL,
and the integrated GPU by HIP and OpenCL each certified, random circuits and
placed jobs the CPU's bits, the split included; the CPU's OpenCL wider kernels
do not certify and it runs only narrow ones. CI legs updated (four
state-vector tests, six placement tests, the wide certificate checked); agent
docs re-blessed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

29c8c24594

• View at this point in history

2026-10-31 22:05:00 -04:00