tracel-ai/burn · error

Invalid concreate ref layout

Error message

Invalid concreate ref layout

What it means

This panic fires in the elementwise fusion optimization's `run` when it resolves the shape for the fused kernel launch. `RefLayout::Concrete` must point at a `FuseArg::Input` or `FuseArg::Output`; any other FuseArg variant (e.g. a local/constant arg) reaching a Concrete ref layout is an internal invariant violation of the fusion optimizer.

Source

Thrown at crates/burn-cubecl-fusion/src/optim/elemwise/optimization.rs:96

pub struct ElemwiseRunner;

impl Vectorization for ElemwiseRunner {}
impl TraceRunner for ElemwiseRunner {
    type Error = LaunchError; // No error possible

    fn run<'a>(
        &'a self,
        client: &'a Client,
        inputs: GlobalArgsLaunch,
        outputs: GlobalArgsLaunch,
        configs: &[FuseBlockConfig],
    ) -> Result<(), Self::Error> {
        let config = &configs[0];
        let shape = match &config.ref_layout {
            RefLayout::Concrete(arg) => match arg {
                FuseArg::Input(..) => inputs.shape_ref(&config.ref_layout, config.rank),
                FuseArg::Output(..) => outputs.shape_ref(&config.ref_layout, config.rank),
                _ => panic!("Invalid concreate ref layout"),
            },
            RefLayout::Virtual(_) => inputs.shape_ref(&config.ref_layout, config.rank),
        };
        let working_units = shape.iter().product::<usize>() / config.width;
        let cube_dim = CubeDim::new(client, working_units);
        let cube_count = calculate_cube_count_elemwise(client, working_units, cube_dim);
        let address_type = inputs
            .required_address_type()
            .max(outputs.required_address_type());

        unsafe {
            elemwise_fuse::launch_unchecked(
                client,
                cube_count,
                cube_dim,
                address_type,
                inputs,
                outputs,

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Check which code constructs the RefLayout::Concrete and ensure it only ever wraps FuseArg::Input or FuseArg::Output
2. If using a custom fusion provider, audit your optimization's ref_layout construction
3. Update burn and burn-cubecl-fusion together; this is likely an internal bug — file an issue with the fusion config

Example fix

// before
RefLayout::Concrete(FuseArg::Scalar(..)) // invalid
// after
RefLayout::Concrete(FuseArg::Input(pos, ..)) // or FuseArg::Output(pos, ..)

if let RefLayout::Concrete(FuseArg::Input(_) | FuseArg::Output(_)) = &config.ref_layout {
    // safe to run
} else {
    // reject or rebuild the optimization config
}

fn is_concrete_input_or_output(l: &RefLayout) -> bool {
    matches!(l, RefLayout::Concrete(FuseArg::Input(..) | FuseArg::Output(..)) | RefLayout::Virtual(_))
}

When it happens

Trigger: Running a fused elementwise kernel whose `RefLayout::Concrete` wraps a FuseArg variant other than Input or Output — i.e. a bug in optimization construction, not in user code.

Common situations: Custom fusion optimization providers built against burn-cubecl-fusion internals; serialized/restored fusion states produced by a different burn version whose FuseArg enum changed.

Related errors

• Input must be concrete
• Invalid ref layout
• Not a valid DType for tensors.
• irfft kernel launch failed (device={input_device:?}, dtype={
• Unsupported grid_sample interpolation mode: {:?}

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