tracel-ai/burn · error

Not a valid DType for tensors.

Error message

Not a valid DType for tensors.

What it means

`elem_type_to_dtype` converts a cubecl `ElemType` into a burn `DType`. `FloatKind::TF32` has no corresponding tensor DType in burn, so mapping it panics. TF32 exists in cubecl only as a GPU compute mode, not as a storable tensor dtype.

Source

Thrown at crates/burn-backend/src/cubecl.rs:38

pub use cubecl::Device;
/// Which runtime a [`Device`] belongs to. Re-exported alongside it: with one
/// backend covering every runtime, naming a runtime is how a caller asks for a
/// subset of the devices.
pub use cubecl::RuntimeId;
pub use cubecl::std::throughput::measure_peak_throughput;

/// Convert a cubecl [`ElemType`] into the corresponding burn [`DType`].
///
/// Panics if the cubecl type has no direct burn equivalent (e.g. `TF32`).
pub fn elem_type_to_dtype(value: ElemType) -> DType {
    match value {
        ElemType::Float(float_kind) => match float_kind {
            FloatKind::F16 => DType::F16,
            FloatKind::BF16 => DType::BF16,
            FloatKind::Flex32 => DType::Flex32,
            FloatKind::F32 => DType::F32,
            FloatKind::F64 => DType::F64,
            FloatKind::TF32 => panic!("Not a valid DType for tensors."),
            FloatKind::E2M1
            | FloatKind::E2M1x2
            | FloatKind::E2M3
            | FloatKind::E3M2
            | FloatKind::E4M3
            | FloatKind::E5M2
            | FloatKind::UE8M0 => {
                unimplemented!("Not yet supported, will be used for quantization")
            }
        },
        ElemType::Int(int_kind) => match int_kind {
            IntKind::I8 => DType::I8,
            IntKind::I16 => DType::I16,
            IntKind::I32 => DType::I32,
            IntKind::I64 => DType::I64,
        },
        ElemType::UInt(uint_kind) => match uint_kind {
            UIntKind::U8 => DType::U8,

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Use `FloatKind::F32` (or F16/BF16/Flex32) as the tensor storage elem type instead of TF32; TF32 is only valid for internal compute.
2. In the kernel, keep TF32 math internally but declare the output buffer as F32.
3. If an autotune config triggers this, restrict the autotune key/combinations to non-TF32 output types.

Example fix

// before
let elem = ElemType::Float(FloatKind::TF32);
let dtype = elem_type_to_dtype(elem); // panics

// after
let elem = ElemType::Float(FloatKind::F32);
let dtype = elem_type_to_dtype(elem);

// reject TF32 as a storage elem type before conversion
if matches!(elem_type, cubecl::ir::ElemType::Float(cubecl::ir::FloatKind::TF32)) {
    // use F32 storage; TF32 is compute-only
}

fn tensor_elem_type(e: &cubecl::ir::ElemType) -> Option<cubecl::ir::ElemType> {
    match e {
        cubecl::ir::ElemType::Float(cubecl::ir::FloatKind::TF32) => {
            Some(cubecl::ir::ElemType::Float(cubecl::ir::FloatKind::F32))
        }
        _ => Some(e.clone()),
    }
}

When it happens

Trigger: Any code path calling `elem_type_to_dtype` (cubecl kernel `run`, `reduce_logical`, `reduce_dim_with_indices`, `init_reduce_output`) with a kernel whose element type resolves to `ElemType::Float(FloatKind::TF32)`.

Common situations: Writing a custom cubecl kernel with `ElemType::Float(FloatKind::TF32)` output and bridging it back into a burn tensor; autotune selecting a TF32 kernel config whose output must be materialized; copy-pasting kernel code using TF32 for storage.

Related errors

• Can't store native sub-byte values
• Unsupported dtype for `float_from_data`
• Quantization scheme is not valid for dtype {other:?}
• {other:?} doesn't support native packing
• Invalid concreate ref layout

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