Skip to main content

Module buffer

Module buffer 

Source
Expand description

Typed buffer wrappers — Phase B foundation.

Each backend grows a wrapper struct that carries a runtime Dtype tag alongside the raw storage. The wrappers are not yet wired to Backend::Buffer (that’s Phase B-2: switch type Buffer = ... per backend + migrate all callsites). For now they exist as separate types so Phase B-2 can be staged without breaking everything in one go.

Pattern mirrors the existing MetalBuf (see backend::metal::MetalBuf) which has been carrying a dtype tag since the Metal backend shipped. Generalising it to CPU + CUDA eliminates the from_slice_i32 / alloc_u32 / write_u32 family of helpers that tunnel integer data through the FP-typed buffer.

Migration plan (next PR):

  1. Replace each backend’s type Buffer = <concrete> with the typed wrapper.
  2. Add forwarder methods so existing call sites compile unchanged (buf.as_f16() / buf.as_f32_slice() / buf.as_u32_mut() etc.).
  3. Replace alloc_u32 / from_slice_i32 / write_u32 with one Self::alloc(Dtype, n) and one Self::write_typed(buf, &[T]).
  4. Delete the legacy helpers + their i32 bit-cast tunnels.

Enums§

CpuBuf
CPU-side typed buffer. Variants per dtype keep storage typed (no unsafe bytemuck casting, no alignment concerns). Compared to a (Vec<u8>, Dtype, n) triple this trades 16 bytes of discriminant for type safety on a non-hot-path (CPU is the slow path; if you care about throughput here, switch backends).