You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Bug] MiniMax-H3 I2VA/FL2VA: ROCm VAE encode crashes with 0xC0000005 (ACCESS_VIOLATION) on Windows
sd-cli version: stable-diffusion.cpp version unknown, commit 97d2990 (pre-built Windows ROCm binary, ~2026-08-19) OS: Windows 11 GPU: AMD Radeon RX 7900 XTX (gfx1100, 24GB VRAM / 23.7GB usable) ROCm: ROCm 7.14.0 (bundled with the pre-built binary)
Description
MiniMax-H3 I2VA (image-to-video+audio) and FL2VA (first+last frame → video+audio) modes crash with exit code 3221225725 (0xC0000005, STATUS_ACCESS_VIOLATION) when using the ROCm HIP backend (--backend llm=cpu,vae=ROCm0,diffusion=ROCm0).
The crash is deterministic (100% reproduction rate) and occurs during VAE encode of the input image — the very first GPU operation after model loading. The diffusion sampling and VAE decode stages are never reached.
The crash also occurs without--offload-to-cpu, with --max-vram values 14–22, and with or without --eager-load. The only variable that matters is the backend: vae=ROCm0 always crashes; vae=Vulkan1 always works.
Via menu
Select backend [5] ROCm+VAE乒乓, model pruned, mode I2VA, provide an input image. The auto-route (menu [4]) correctly avoids this by sending I2VA/FL2VA to Vulkan — the crash only happens when ROCm is explicitly selected.
The image preprocessing (crop + resize) completes successfully, and all four model files load and initialize normally. The crash happens at the instant the VAE encode graph is computed on ROCm0 — 118 tensors (344MB) are staged to VRAM, then the compute buffer is allocated (627MB), and immediately the process dies with an access violation. No error message from the HIP runtime, no user-mode exception handling.
Successful Vulkan comparison (same config, same hardware)
Running the identical config with --backend llm=cpu,vae=Vulkan1,diffusion=Vulkan1 completes successfully:
Not an OOM: VRAM during load is 0MB (all weights in RAM via --offload-to-cpu), and the encode only needs 344MB staged + 627MB compute buffer = ~1GB, well within 23.7GB available. The same config runs to completion on Vulkan with the same VRAM budget.
Not model-specific: Both minimax_h3_fl2va_pruned-Q4_K_M (11GB) and minimax_h3_fl2va-Q4_K_M (18GB, full) models crash identically when I2VA/FL2VA is used on ROCm.
Not input-image-specific: Tested with various input images (768×1368, 2048×2048, diverse content) — all crash at the same point.
Not mitigatable: --offload-to-cpu, different --max-vram values (14–22), --eager-load, --vae-on-cpu (deprecated) — none prevent the crash. The only working VAE encode path on this hardware is Vulkan.
Hypothesis
The MiniMax-H3 video VAE (minimax_h3_video_vae_fp16.safetensors, 5.6GB, 562 tensors) is a custom architecture that differs from the standard SD VAE — it has a 24-channel latent space, temporal clip length 17, and uses tiled encoding. The ggml HIP backend for ROCm likely has a bug in one of the operations used by the VAE encoder graph (possibly a 2D convolution, a memory layout/view operation, or the tiled overlap handling) that causes an out-of-bounds memory access. The Vulkan backend handles the same computation graph without issue, suggesting the bug is in the HIP kernel implementation, not in the model itself or the higher-level VAE code.
Additional context: T2V/T2VA works fine on ROCm
Text-only modes (T2V/T2VA, no image input, no VAE encode needed) run flawlessly on the same ROCm binary — including VAE decode during the final video assembly. The VAE decode path uses the same model weights but different graph operations, and it completes successfully. This strongly points to a bug specific to the VAE encode graph's kernel set on the ROCm HIP backend.
Attachments
Full crash log (from --verbose output): the log above is the complete relevant portion; the model loading section (before the crash) is unremarkable — all four models load without warnings.
[Bug] MiniMax-H3 I2VA/FL2VA: ROCm VAE encode crashes with 0xC0000005 (ACCESS_VIOLATION) on Windows
sd-cli version:
stable-diffusion.cpp version unknown, commit 97d2990(pre-built Windows ROCm binary, ~2026-08-19)OS: Windows 11
GPU: AMD Radeon RX 7900 XTX (gfx1100, 24GB VRAM / 23.7GB usable)
ROCm: ROCm 7.14.0 (bundled with the pre-built binary)
Description
MiniMax-H3 I2VA (image-to-video+audio) and FL2VA (first+last frame → video+audio) modes crash with exit code
3221225725(0xC0000005,STATUS_ACCESS_VIOLATION) when using the ROCm HIP backend (--backend llm=cpu,vae=ROCm0,diffusion=ROCm0).The crash is deterministic (100% reproduction rate) and occurs during VAE encode of the input image — the very first GPU operation after model loading. The diffusion sampling and VAE decode stages are never reached.
Reproduction
Command line
sd-cli.exe --mode vid_gen \ -p "<lora:minimax_h3_turbo_v11_sdcpp:1.0> 美女说,树青,听说你去洱海了。" \ --init-image input.png \ --width 480 --height 864 \ --video-frames 175 \ --sample-steps 5 --flow-shift 6 --cfg-scale 1.0 \ --seed 42 \ --backend llm=cpu,vae=ROCm0,diffusion=ROCm0 \ --offload-to-cpu \ --eager-load \ --lora-model-dir ./models/MiniMax-H3/loras \ --lora-apply-mode at_runtime \ --diffusion-fa \ --max-vram ROCm0=22The crash also occurs without
--offload-to-cpu, with--max-vramvalues 14–22, and with or without--eager-load. The only variable that matters is the backend:vae=ROCm0always crashes;vae=Vulkan1always works.Via menu
Select backend [5] ROCm+VAE乒乓, model pruned, mode I2VA, provide an input image. The auto-route (menu [4]) correctly avoids this by sending I2VA/FL2VA to Vulkan — the crash only happens when ROCm is explicitly selected.
Crash log
The image preprocessing (crop + resize) completes successfully, and all four model files load and initialize normally. The crash happens at the instant the VAE encode graph is computed on ROCm0 — 118 tensors (344MB) are staged to VRAM, then the compute buffer is allocated (627MB), and immediately the process dies with an access violation. No error message from the HIP runtime, no user-mode exception handling.
Successful Vulkan comparison (same config, same hardware)
Running the identical config with
--backend llm=cpu,vae=Vulkan1,diffusion=Vulkan1completes successfully:What has been ruled out
minimax_h3_video_vae), not the diffusion model's graph. The encode path has never been patched.--offload-to-cpu), and the encode only needs 344MB staged + 627MB compute buffer = ~1GB, well within 23.7GB available. The same config runs to completion on Vulkan with the same VRAM budget.minimax_h3_fl2va_pruned-Q4_K_M(11GB) andminimax_h3_fl2va-Q4_K_M(18GB, full) models crash identically when I2VA/FL2VA is used on ROCm.--offload-to-cpu, different--max-vramvalues (14–22),--eager-load,--vae-on-cpu(deprecated) — none prevent the crash. The only working VAE encode path on this hardware is Vulkan.Hypothesis
The MiniMax-H3 video VAE (
minimax_h3_video_vae_fp16.safetensors, 5.6GB, 562 tensors) is a custom architecture that differs from the standard SD VAE — it has a 24-channel latent space, temporal clip length 17, and uses tiled encoding. The ggml HIP backend for ROCm likely has a bug in one of the operations used by the VAE encoder graph (possibly a 2D convolution, a memory layout/view operation, or the tiled overlap handling) that causes an out-of-bounds memory access. The Vulkan backend handles the same computation graph without issue, suggesting the bug is in the HIP kernel implementation, not in the model itself or the higher-level VAE code.Additional context: T2V/T2VA works fine on ROCm
Text-only modes (T2V/T2VA, no image input, no VAE encode needed) run flawlessly on the same ROCm binary — including VAE decode during the final video assembly. The VAE decode path uses the same model weights but different graph operations, and it completes successfully. This strongly points to a bug specific to the VAE encode graph's kernel set on the ROCm HIP backend.
Attachments
--verboseoutput): the log above is the complete relevant portion; the model loading section (before the crash) is unremarkable — all four models load without warnings.