Skip to main content

Crate fuel_memory

Crate fuel_memory 

Source
Expand description

§fuel-storage

Unified storage abstraction for fuel. Phase 7.5 foundation work item (see docs/storage-unification.md).

Storage is the single entry point that holds bytes, a dtype tag, and a backend memory region (closed enum over CPU/CUDA/Vulkan/Metal). Backends provide kernels that operate on these types — backend storage types live in their own crates and implement the fuel_ir::backend::BackendStorage trait.

This crate now owns ONLY the closed-enum dispatch wrapper + the public Storage API. Dispatch infrastructure (KernelBindingTable, registration wrappers, CompiledNode, ExecutionPlan, the picker, FusedKernelRegistry, cost functions, the PipelinedExecutor) was extracted to fuel-dispatch 2026-05-31; see docs/session-prompts/dispatch-move-to-fuel-core.md for the move’s rationale.

§Where things live

  • fuel_ir::backend::BackendStorage — the abstract trait (just len_bytes() today; alloc/copy_from land in A4).
  • fuel_cpu_backend::CpuStorageBytes — CPU storage (Phase A3.0). Bytes-based, 64-byte aligned, Arc-clonable, CoW on mutation.
  • fuel_metal_backend::MetalStorageBytes — Metal storage (A3.1).
  • fuel_cuda_backend::CudaStorageBytes — CUDA storage (A3.2).
  • fuel_vulkan_backend::VulkanStorageBytes — Vulkan storage (A3.3).
  • fuel_dispatch — every binding-table, registration wrapper, picker, executor, and cost-fn that used to live here.

Macros§

dispatch_storage
Feature-aware match over BackendStorage variants. Used wherever the dispatch shape match s { Cpu(...) => ..., Cuda(...) => ... } would otherwise need #[cfg(feature = "...")] arms inline.

Structs§

Storage
Top-level storage type: byte-erased payload + runtime dtype tag. Layout (shape + strides + start_offset) lives separately on the consuming Tensor — Storage owns only the bytes and which device/dtype they represent.

Enums§

BackendStorage
Closed enum over backend storage variants. The Cpu variant holds CpuStorageBytes from fuel-cpu-backend. GPU variants (feature-gated) hold the per-backend *StorageBytes types from each backend crate.

Functions§

alloc_cpu_zeroed
Allocate freshly on the CPU backend with the given dtype + element count. Bytes are zero-initialized and 64-byte aligned (suitable for AVX-512 SIMD).
from_slice_cpu
Build a CPU Storage from a typed slice, copying the bytes. The result has the dtype matching T and is 64-byte aligned.