Crate ferrox_cuda 

ferrox-cuda: hardware capability detection (always compiled, always tested) plus an optional, feature-gated CUDA execution path.

Build without any GPU support (the default): cargo build -p ferrox-cuda. Build with the CUDA scaffolding included: cargo build -p ferrox-cuda --features cuda.

The cuda feature compiles cleanly in this development sandbox (which has neither a CUDA toolkit nor a GPU) because cudarc is configured for dynamic loading – the driver and NVRTC libraries are dlopen’d at runtime, not linked at build time. That means “this crate compiles with --features cuda” is a true, checked fact. It does not mean the CUDA kernels in gpu.rs have ever executed successfully; see that module’s docs for exactly what has and has not been verified.

Re-exports

pub use capability::HardwareProfile;

pub use capability::SimdCaps;

Modules

capability

Runtime hardware capability detection: probe once, report a plain struct, and let every performance-relevant decision (thread pool width, SIMD kernel selection, GPU residency) derive from the detected machine rather than being hardcoded. Ferrox today only has a CPU execution path, so HardwareProfile::detect() is honest about that: the CUDA fields are always populated (zero / false / None) unless built with --features cuda, and even then they report exactly what ferrox-cuda’s device probe finds, no more.

mul_mm

The mul_mm kernel source and its per-quant-kind dispatch table. Always compiled: it is CUDA C text plus a scalar twin, neither of which needs cudarc, so the default cargo test -p ferrox-cuda run on a GPU-less host still exercises the arithmetic the kernel encodes. Only the launch path ([mul_mm_launch]) is feature-gated. mul_mm: a batched quantized GEMM for CUDA – the CUDA C source and the per-quant-kind dispatch table.

mul_mm_ref

The scalar twin of the CUDA mul_mm kernel: the same GEMM, executed on the host, one emulated threadblock at a time.