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

Error message

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

What it means

The rfft kernel launch itself returned an error (e.g. kernel compilation failure, out-of-memory, invalid launch configuration); the wrapper panics with a diagnostic message containing device, dtype, dim, requested_n, and fft_size to aid debugging.

Source

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

        signal.dtype,
    );
    let output_im = empty_device_dtype(
        signal.client.clone(),
        signal.device.clone(),
        output_shape.clone(),
        signal.dtype,
    );

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

    (output_re, output_im)
}

/// Launch the irfft kernel with optional padding for non-power-of-two sizes.
pub fn irfft(
    spectrum_re: CubeTensor,
    spectrum_im: CubeTensor,
    dim: usize,
    n: Option<usize>,
) -> CubeTensor {
    assert!(
        spectrum_re.shape() == spectrum_im.shape(),
        "irfft: spectrum_re and spectrum_im shapes must match"

View on GitHub (pinned to d16f7ba2ed)

Solutions

Read the wrapped error `e` in the panic message for the root cause
Reduce `n`/input size or chunk the signal to fit in GPU memory
Verify the backend (wgpu/cuda) supports the FFT kernels and update burn/cubecl
Run on a different device to rule out driver issues

Defensive patterns

Strategy: fallback

Validate before calling

// estimate padded buffer size before calling
let n = n.unwrap_or(signal.shape()[dim]);
let fft_size = n.next_power_of_two();
let elems = signal.shape().iter().product::<usize>() / signal.shape()[dim] * fft_size;
assert!(elems * 4 < free_gpu_memory_hint(), "FFT buffer may exceed GPU memory");

Try / catch

// panic-based API; isolate and fall back:
let result = std::panic::catch_unwind(|| tensor.clone().rfft(dim, n));
match result {
    Ok((re, im)) => { /* use outputs */ },
    Err(_) => { /* retry on CPU backend or with smaller n */ }
}

Prevention

Keep n modest or chunk long signals to bound memory
Keep GPU drivers and burn/cubecl updated
Test FFT on the target backend early in development
Use device with sufficient free memory for pow2-padded buffers

When it happens

Trigger: GPU kernel launch failure inside `rfft`: unsupported/failed kernel compilation on the backend, insufficient memory for the pow2-padded FFT buffer, or a device/runtime error from the compute backend.

Common situations: Very large `n` values exhausting GPU memory after power-of-two padding; experimental/unstable backends lacking the FFT kernel; driver/runtime issues on the target device.

Related errors

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