tracel-ai/burn · error

irfft kernel launch failed (device={input_device:?}, dtype={

Error message

irfft kernel launch failed (device={input_device:?}, dtype={input_dtype:?}, dim={dim}, requested_n={requested_n}, fft_size={fft_size}): {e}

What it means

This panic fires when the irfft (inverse real FFT) CubeCL kernel fails to launch. The message includes the input device, dtype, the dimension being transformed, the requested output length n, and the inferred FFT size, plus the underlying kernel error. The library panics because a failed kernel launch is unrecoverable at this API level.

Source

Thrown at crates/burn-cubecl/src/kernel/fft/base.rs:145

    signal_shape[dim] = fft_size;

    let signal = empty_device_dtype(
        spectrum_re.client.clone(),
        spectrum_re.device.clone(),
        signal_shape,
        spectrum_re.dtype,
    );

    irfft_launch(
        &spectrum_re.client.clone(),
        spectrum_re.binding(),
        spectrum_im.binding(),
        signal.clone().binding(),
        dim,
        dtype,
    )
    .unwrap_or_else(|e| {
        panic!(
            "irfft kernel launch failed (device={input_device:?}, dtype={input_dtype:?}, \
             dim={dim}, requested_n={requested_n}, fft_size={fft_size}): {e}"
        )
    });

    if fft_size > requested_n {
        pad_to_length(signal, dim, requested_n)
    } else {
        signal
    }
}

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Verify the spectrum tensor has the expected shape (last dim = n/2+1 along `dim`) and dtype supported by the backend
2. Check the tensor is on a device whose runtime supports the FFT kernel for this dtype
3. Read the wrapped error `{e}` for the concrete launch failure (compilation vs out-of-bounds)
4. Reduce to a smaller n / supported dim to isolate whether size or dtype is the problem

Example fix

// before
let out = input.irfft(256, 2);
// after: ensure spectrum shape matches requested n along dim
assert_eq!(input.shape().dims[2], 256 / 2 + 1);
let out = input.irfft(256, 2);

assert!(matches!(input.dtype, DType::F32 | DType::F16), "unsupported irfft dtype");
assert!(dim < input.dims().len(), "irfft dim out of range");
assert_eq!(input.dims()[dim], requested_n / 2 + 1, "spectrum shape mismatch");

When it happens

Trigger: Calling irfft on a CubeTensor whose dtype or device is not supported by the compiled kernel, passing a dim out of range for the tensor rank, or an invalid spectrum shape so requested_n/fft_size are inconsistent; also when the backend returns a launch/compilation error.

Common situations: Running on a GPU runtime where the FFT kernel is not compiled for the dtype (e.g. f16 on hardware without support), transforming an innermost dim with a spectrum whose last dimension doesn't match fft_size/2+1, or mismatches after moving tensors between devices.

Related errors

• rfft kernel launch failed (device={input_device:?}, dtype={i
• interpolate_backward kernel failed (device={0:?}, dtype={1:?
• {0} kernel failed (device={1:?}, dtype={2:?}): {3}
• Not a valid DType for tensors.
• Invalid concreate ref layout

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