tracel-ai/burn · error

unsupported dtype: {:?}

Error message

unsupported dtype: {:?}

What it means

The burn-ndarray `execute_with_dtype!` macro dispatches an operation on the tensor's runtime DType to a typed arm (f32, i32, bool, etc.). If the tensor's dtype matches none of the arms, the catch-all `other` arm panics with `unimplemented!("unsupported dtype: {:?}")`. This is a compile-time-dispatch limitation: the backend only implements the listed element types, so exotic dtypes (e.g. f64, i16, quantized) cannot run.

Source

Thrown at crates/burn-ndarray/src/tensor.rs:166

            F64 => f64, F32 => f32,
            I64 => i64, I32 => i32, I16 => i16, I8 => i8,
            U64 => u64, U32 => u32, U16 => u16, U8 => u8,
            Bool => bool
        ])
    }};

    ($tensor:expr, $element:ident, $op:expr, [$($dtype: ident => $ty: ty),*]) => {{
        match $tensor {
            $(
                $crate::NdArrayTensor::$dtype(storage) => {
                    #[allow(unused)]
                    type $element = $ty;
                    // Convert to SharedArray for compatibility with most operations
                    $op(storage.into_shared()).into()
                }
            )*
            #[allow(unreachable_patterns)]
            other => unimplemented!("unsupported dtype: {:?}", other.dtype())
        }
    }};
    // Unary op: type automatically inferred by the compiler
    ($tensor:expr, $op:expr) => {{
        $crate::execute_with_dtype!($tensor, E, $op)
    }};

    // Unary op: generic type cannot be inferred for an operation
    ($tensor:expr, $element:ident, $op:expr) => {{
        $crate::execute_with_dtype!($tensor, $element, $op, [
            F64 => f64, F32 => f32,
            I64 => i64, I32 => i32, I16 => i16, I8 => i8,
            U64 => u64, U32 => u32, U16 => u16, U8 => u8,
            Bool => bool
        ])
    }};
}

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Cast the tensor to a supported dtype before the operation (e.g. `.cast(burn::tensor::DType::F32)`).
2. Enable/compile the backend feature that includes the needed dtype (e.g. f64/i64 features for burn-ndarray).
3. If the model weights are f64, convert the weights to f32 at load/export time.
4. Check which dtypes the backend supports and align model/export configuration accordingly.

Example fix

// before
let w: Tensor<B, 2> = Tensor::from_floats([f64_data], &device).cast(DType::F64);
let out = w.matmul(&x);
// after
let out = w.cast(DType::F32).matmul(&x);

fn assert_supported_dtype<B: Backend>(t: &Tensor<B, 2>) -> bool {
    matches!(t.dtype(), DType::F32 | DType::I32 | DType::Bool)
}
if !assert_supported_dtype(&t) { t = t.cast(DType::F32); }

fn is_supported_dtype(d: DType) -> bool {
    matches!(d, DType::F32 | DType::I64 | DType::I32 | DType::U32 | DType::U8 | DType::Bool | DType::F16 | DType::BF16)
}

When it happens

Trigger: Calling any tensor operation via the NdArray backend on a tensor whose dtype is not one of the dtypes expanded by the macro (e.g. F64, I64, I16, quantized tensors), such as running a model that requires f64 precision or an op on an unsupported numeric type.

Common situations: Loading a checkpoint or model exported with f64/i64 weights into an ndarray backend compiled only for f32/i32; using a dtype added in a newer burn version while the backend macro arms were not extended; feeding CPU numpy data without casting to supported dtypes.

Related errors

• float_storage_as_f32: unsupported dtype {:?}
• conv1d: unsupported dtype {:?}
• conv2d: unsupported dtype {:?}
• conv3d: unsupported dtype {:?}
• conv_transpose1d: unsupported dtype {:?}

AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/949a6c416b0fef86. Report an issue: GitHub.