SIGFPE (division by zero) in ggml_conv_3d during Wan2.2 TI2V-5B image-to-video generation

[basementops]

Description

Running Wan2.2-TI2V-5B in image-to-video mode (-i <image>) crashes with SIGFPE (division by zero) before the first sampling step. Confirmed on two different commits, both after 97d2990 (2026-08-19), which still works correctly:

• d8fb10c (2026-09-07, ROCm/HIP build)
• c678dfe (2026-09-20, Vulkan build) — current master as of this report

A parallel Flux-2 run (2D conv path) on the same c678dfe build was unaffected, so this looks specific to the 3D-conv path used by Wan.

Environment

• OS: Debian 13
• GPU: AMD Ryzen AI Max+ 395 (Strix Halo), Radeon Graphics gfx1151 (RDNA3.5, APU/Unified Memory)
• Build tested here: cmake -B build -DSD_VULKAN=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo, Mesa 25.0.7-2, Vulkan 1.3.283
• Also reproduced on a ROCm 7.2.4 (HIP 7.2.53211) build on an earlier commit (see above)

Steps to reproduce

Weights: Wan-AI/Wan2.2-TI2V-5B fp16 diffusion model, official wan2.2_vae.safetensors, umt5-xxl-encoder (Q8_0 GGUF).

sd-cli \
  --diffusion-model wan2.2_ti2v_5B_fp16.safetensors \
  --vae wan2.2_vae.safetensors \
  --t5xxl umt5-xxl-encoder-Q8_0.gguf \
  -i <any reference image> \
  -p "a person standing in a garden, camera slowly zooms in, golden hour lighting" \
  -W 832 -H 480 --cfg-scale 6.0 --flow-shift 3.0 \
  --sampling-method euler --diffusion-fa --offload-to-cpu --video-frames 33 \
  -o out.mp4

Expected behavior

Video generation proceeds to sampling (as it did on 97d2990).

Actual behavior

Crashes with SIGFPE right after model/text-encoder loading, before the first sampling step:

[INFO   ] image.cpp:861  - generating image: 1/1 - seed 42
Program terminated with signal SIGFPE, Arithmetic exception.

Backtrace (RelWithDebInfo build, commit c678dfe)

Thread 1 "sd-cli" received signal SIGFPE, Arithmetic exception.
#0  ggml_conv_3d (ctx=..., a=<optimized out>, b=<optimized out>, IC=48, s0=<optimized out>, s1=<optimized out>, s2=1, p0=0, p1=0, p2=0, d0=1, d1=1, d2=1)
    at ggml/src/ggml.c:4849
        im2col = 0x7fffcef74f90
        OC = 3072
        N = 0
        result = 0x7fffcef75500
4849	    int64_t OD = im2col->ne[3] / N;
#1  ggml_ext_conv_3d (...) at src/core/ggml_extend.cpp:497
#2  Conv3d::forward (...) at src/model/common/ggml_block.hpp:731
#3  WAN::Wan::forward_orig (this=..., ..., N=1, ...) at src/model/diffusion/wan.hpp:707
#4  WAN::Wan::forward (this=..., ..., N=1, ...) at src/model/diffusion/wan.hpp:868
#5  WAN::WanRunner::build_graph (...) at src/model/diffusion/wan.hpp:1041
#6  WAN::WanRunner::compute(...)::{lambda()#1}::operator()() at src/model/diffusion/wan.hpp:1071

Note that forward_orig/forward are called with N=1 (batch size), but the local N inside ggml_conv_3d at the crash site is 0 — it's computed from tensor shape inside ggml_conv_3d/ggml_ext_conv_3d, not passed through from the caller, so the batch-size-1 case seems to hit a zero somewhere in that local computation.

Additional notes

• No regression on 97d2990 (2026-08-19) — this is a regression introduced sometime between that commit and d8fb10c (2026-09-07), likely from the temporal-tiling refactor around that time (ggml_extend.hpp, wan.hpp/wan_vae.hpp changed significantly).
• Happy to test a patch or provide more info — this is currently blocking us from using any sd.cpp version newer than 97d2990 (which in turn blocks newer model support, e.g. Qwen-Image-2.1).

[leejet]

Thanks for the report. The command shown is missing -M vid_gen. The CLI defaults to img_gen, and --video-frames does not switch modes automatically, which explains the generating image log. Please add -M vid_gen and try again.