Module compute_bridge 

Compute bridge — the engine’s one shared “which hardware runs this kernel” surface (HARDWARE_BACKEND_AUTOSELECT_PLAN.md; CLAUDE.md §13).

Every accelerable STEM function classifies itself into a KernelClass, and at its call site asks ComputePolicy::select for a Plan — which backend (over the open BackendRegistry), which precision, how to tile, how to move data — then runs it. No module hardcodes a device; they all defer to the measured per-class capability matrix. CPU is always present and never fails.

Layers (each its own submodule, plan §11):

• kernel_class — the fixed kernel-shape taxonomy routed per class.
• backend — the open ProbeableBackend registry (the expansion point: a new accelerator is one register(), never an edit to the decision tree).
• [reference] — correct CPU microkernels: the always-present path AND the correctness reference a GPU/NPU/vendor kernel must match before it may default.
• matrix — the per-class capability matrix + the built-in CPU/wgpu backends.
• policy — ComputePolicy::select → Plan (wraps hetero_dispatch).

Native only (it reuses the native wgpu probe + rayon CPU path). A WASM/browser build registers a narrower set (WebGPU-or-CPU); that target-conditional registry is a follow-on (plan §4b).

Re-exports

pub use backend::BackendId;

pub use backend::BackendRegistry;

pub use backend::DispatchError;

pub use backend::KernelPanel;

pub use backend::ProbeableBackend;

pub use execute::accelerated_gemm_f32;

pub use execute::shared_policy;

pub use execute::RanOn;

pub use gpu_gemm::WgpuGemm;

pub use kernel_class::KernelClass;

pub use matrix::probe_class_matrix;

pub use matrix::ClassMatrix;

pub use matrix::CpuBackend;

pub use matrix::WgpuBackend;

pub use policy::ComputePolicy;

pub use policy::Plan;

Modules

backend

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

execute

The dispatch entry the STEM substrate calls: accelerated_gemm_f32 runs C = A·B on the GPU when the measured capability matrix says it wins and the job is big enough to be worth the dispatch, and on a rayon CPU path otherwise. The CPU path is always present and never hard-fails (§7).

gpu_gemm

The portable wgpu f32 GEMM — the execute half of the bridge. Until now compute_bridge only probed and planned; this actually runs a kernel on the GPU and reads the result back, reusing the exact wgpu idioms the capability benchmark (crate::device_benchmark) already uses on this hardware.

kernel_class

Kernel-class taxonomy — the small, fixed set of compute shapes the engine benchmarks and routes per class (HARDWARE_BACKEND_AUTOSELECT_PLAN.md §3).

matrix

The per-class capability matrix and the built-in backends (plan §3).

policy

ComputePolicy — the one shared dispatch surface the whole engine calls (HARDWARE_BACKEND_AUTOSELECT_PLAN.md §4).

reference

CPU reference microkernels — one per KernelClass.

Functions

default_registry

The default backend registry: the always-present native CPU path plus the portable wgpu path. Expansion backends (cuda, rocm, oneapi, NPU runtimes) register here behind their Cargo features — one register() each, no change to ranking or select.