Module backend 

The open backend registry (HARDWARE_BACKEND_AUTOSELECT_PLAN.md §2.2, §4).

The bridge’s expansion point: backends are not a closed enum. Each acceleration method (CPU, the wgpu backends, later CUDA / ROCm / oneAPI / NPU runtimes) is one impl ProbeableBackend registered into a BackendRegistry. The benchmark loop, the ranking, the passport schema and ComputePolicy::select all iterate the registry — so adding a backend is one register() call and never edits the decision tree (the load-bearing requirement). A backend that is not available() on this machine simply contributes no rows.

BackendId is a Copy &'static str so it is zero-heap to pass around and string-keyed in the passport (forward-compatible: a passport written by a core build is still readable by an expansion build — the new backend is just absent and gets probed on next boot).

Structs

BackendId

Stable, string-keyed backend identifier. Copy, zero-heap. Built-ins: "cpu", "wgpu" (which itself reports per-adapter circuits via wgpu’s Vulkan/Dx12/Metal/Gl); expansion ids: "cuda", "rocm", "oneapi", "npu-directml", …

BackendRegistry

The registry of acceleration methods. Heap-using and boot-time only (the heavy probe runs once and is cached in the passport — never on a hot path).

KernelPanel

Per-class problem sizes for the measurement panel. Kept small; cached in the passport so the heavy pass runs once per machine (plan §3 cost guard). quick() shrinks the sizes for low-tier devices / fast boot.

Enums

DispatchError

Why a dispatch could not run on the requested backend. The dispatcher must degrade to CPU on any of these, never panic (plan §7: CPU never hard-fails).

Traits

ProbeableBackend

One acceleration method. Implementors register into a BackendRegistry; the rest of the bridge only ever sees them through this trait, which is why adding a backend never edits select().