Config & Backends

The interface every Deepbox execution backend must implement.

Backends additionally implementing KernelBackend (device-memory kernels, e.g. WebGpuBackend) or HostAcceleratorBackend (host-memory SIMD kernels, e.g. WasmBackend) are picked up automatically by the ndarray dispatch layer once registered. The CPU backend ships as the always-available reference implementation.

Capability flags that a backend may support.

Consumers can query these before dispatching work to avoid runtime surprises on unsupported devices.

Information about a registered backend.

Binary element-wise kernels a backend may execute.

A compiled WASM SIMD module with its exports.

Opaque handle to memory owned by a KernelBackend.

The handle is created by the backend (upload, fill, or as a kernel output) and must be released with free when no longer referenced. Tensors wrap these handles and free them automatically via a finalization registry, but deterministic release via Tensor.dispose() is recommended for large buffers.

Element type of a DeviceBuffer.

float32 is the default (an absent/undefined dtype on a buffer means float32, so all existing code keeps working). float16 is true on-device IEEE-754 half precision (2 bytes/element, requires the WebGPU shader-f16 feature). bfloat16 gives correct bfloat16 numerics to the user via rounding at upload/download while computing on-device in float32, so the WebGPU backend stores it in 4 bytes/element (see Devices & execution).

Information about a compiled GPU pipeline.

Execution interface for host-accelerator backends (e.g. WASM SIMD).

Host accelerators share the CPU address space: tensors on their device keep ordinary TypedArray storage, eligible ops run through the accelerator, and everything else uses the normal CPU implementation. That fallback is safe as long as the accelerator's results are bit-identical IEEE-754 float32 arithmetic, which element-wise add, sub, mul and div are.

Binary ops a host accelerator may run over contiguous float32 data.

Geometry of a 2-D convolution unfold/fold (im2col/col2im), all in elements. The input is [batch, channels, height, width]; the unfolded columns are [batch, outH*outW, channels*kH*kW], laid out for a [channels*kH*kW, outChannels] weight matmul.

Execution interface for accelerated (non-CPU) backends.

Implementations execute kernels over DeviceBuffer memory. All kernels are synchronous from the caller's perspective: they enqueue device work and return a handle immediately. The only asynchronous operation is download, which must wait for in-flight work targeting the buffer to complete before resolving (WebGPU readback is inherently async, which is why Tensor.to('cpu') returns a promise).

Register an implementation with registerBackend(device, backend); the ndarray dispatch layer picks it up automatically for tensors created on (or moved to) that device.

Explicit memory layout of one kernel operand.

Strides and offset are measured in elements (not bytes). A dimension broadcast to the output shape is expressed with stride 0.

2-D pooling kernels a backend may execute.

Full-tensor reduction kernels a backend may execute.

Available shader names.

Ternary element-wise kernels a backend may execute. where selects a where the condition (first operand) is non-zero, else b.

Unary element-wise kernels a backend may execute. copy materializes a strided view; step is the Heaviside step (1 where x > 0, else 0), used by autograd for the relu backward mask.

Available WASM module names.

Global configuration for Deepbox.