Vitis AI compiler crash: "doesn't have __layer_tiling_params attribute" on Resize op with 841-dim (29²) frequency axis

[GiuseppeCapaldo93]

Summary

Compiling a quantized ONNX model containing a Resize node with an input dimension of 841 (=29²) causes a fatal crash in the Vitis AI NPU compiler during subgraph tiling, on both A8W8 and XINT8 quantization schemes.

Environment

• Hardware: AMD Ryzen 7 PRO 8840HS (Hawk Point, XDNA1 NPU)
• NPU driver: 32.0.20102.3930
• Ryzen AI Software: 1.8.0
• AMD Quark: 0.12.post1
• onnxruntime: 1.27.0 (with VitisAIExecutionProvider)
• OS: Windows 11 (build 26100)

Steps to Reproduce

1. Export/obtain an ONNX model containing a Resize op operating on a tensor shaped [1, 841, 128] (STFT magnitude spectrogram from a speech enhancement U-Net, n_fft=1680, freq_bins = n_fft/2+1 = 841)
2. Fix dynamic axes to static shape using onnxruntime.tools.make_dynamic_shape_fixed
3. Quantize with AMD Quark using get_default_config("XINT8") (or "A8W8") via ModelQuantizer.quantize_model()
4. Load the quantized model with:

   session = onnxruntime.InferenceSession(
       quantized_model_path,
       providers=["VitisAIExecutionProvider", "CPUExecutionProvider"],
   )

5. Session creation crashes with a fatal (non-catchable) native exception during compilation

Actual behavior

F20260821 14:09:38.078748 25260 LayerTilingParams.cpp:116] xir::Subgraph{name = 
subgraph_(/net/encoder_blocks.0/downsample/Resize_output_0_vaip_28), child_num = 0, ops_num = 1} 
doesn't have __layer_tiling_params attribute.
2026-08-21 14:09:38.0922779 [F:onnxruntime:, LayerTilingParams.cpp:116 LayerTilingParams.cpp] 
xir::Subgraph{...} doesn't have __layer_tiling_params attribute.
*** Check failure stack trace: ***

The process aborts with a fatal native check failure (not a catchable Python/C++ exception) — the whole process terminates.

Expected behavior

Either:

• The compiler should successfully tile this Resize op, or
• It should gracefully fall back to CPU execution for this op (as it does for other unsupported op types, e.g. qlinear-groupnorm, which correctly logs is partitioned to CPU as: ... does not support ... and continues), or
• It should raise a catchable Python exception instead of a fatal process-aborting check failure

What I've tried (all reproduce the identical crash on the identical node)

1. ✅ Quantizing with A8W8 — crashes
2. ✅ Quantizing with XINT8 — crashes (identical stack trace/node)
3. ✅ Setting nodes_to_exclude in QuantizationConfig to exclude all 8 Resize nodes by name — crashes identically. Inspection of the output ONNX graph confirms the Resize node then receives a DequantizeLinear output as input (i.e., it is excluded from quantization), but the Vitis AI partitioner still attempts to include it in a compiled NPU subgraph, triggering the same tiling failure.
4. ✅ Setting subgraphs_to_exclude — same result. Source inspection (quark/onnx/quantization/quantize.py line 391 and 782) shows this parameter is merged into nodes_to_exclude internally (nodes_to_exclude = get_all_target_nodes(float_model, nodes_to_exclude + subgraphs_to_exclude)), so it has the identical effect as Fix 404 on Microsoft Olive #3, not a true NPU-subgraph-exclusion mechanism.

Suspected root cause

The frequency dimension of the model is 841 = 29². This is a prime-squared value with no small factors (no divisibility by 2, 4, 8, 16, etc.), which is unusual for CNN feature maps (which are typically powers of 2, e.g. 256/512/1024). This may violate an assumption in the AIE tiling algorithm that expects dimensions divisible by small tile sizes.

Minimal repro model

Happy to provide the exact quantized ONNX model file (11.5MB) and/or a minimal Python script reproducing this from a public pretrained model (resemble-ai/resemble-enhance, ONNX export via skeskinen/resemble-denoise-onnx-inference) on request.

Ask

1. Is there a supported way to force a specific node/op out of NPU compilation entirely (distinct from nodes_to_exclude, which only controls quantization precision, not partitioner subgraph assignment)?
2. Is the 841-dim hypothesis correct, and if so, is there a workaround (e.g. padding to a tile-friendly dimension like 848 or 864)?
3. Could the compiler at least fail gracefully (partition to CPU) instead of a fatal process abort, matching the behavior for other unsupported ops?