[Bug] vulkan: SIGABRT when matmul grid exceeds maxComputeWorkGroupCount (krea2 / Qwen3VL edit, 2 reference images, n=2703360)

[akhenakh]

Git commit

stable-diffusion.cpp @ cc515a0
ggml submodule @ e20c3a1

Operating System & Version

Arch Linux, Mesa 26.2.2-arch1.1, Vulkan 1.4.354 (RADV NAVI31), CPU AMD Ryzen 9 7900X

GGML backends

Vulkan

Command-line arguments used

sd-cli -M img_gen \ --diffusion-model /opt/ml/krea/diffusion_models/Krea-2-Turbo-Q8_0.gguf \ --llm /opt/ml/text_encoders/qwen3vl4bAbliterated.iVzM.safetensors \ --vae /opt/ml/krea/vae/qwen_image_vae_diffusers.safetensors \ --backend vulkan1,te=cpu \ --lora-model-dir ./loras \ --lora-apply-mode immediately \ -p "edit the image 1 to add the man from image 2 right of the dog lora:krea2_identity_edit_v1_2:1" \ -r ref1.png -r ref2.png \ -W 640 -H 960 --steps 7 --cfg-scale 1 --img-cfg-scale 1 --flow-shift 3 \ -s 1502861482 --diffusion-fa \ -o out.png

Steps to reproduce

Just run the command

What you expected to happen

The edit generation should run and produce a 640×960 image.

What actually happened

Abort during the first sampling pass. The f32 matmul in the krea2 (Qwen3VL-conditioned) graph has m=1, n=2703360, k large; the pipeline selector chose the small-tile shader matmul_f32_f32_s with wg_denoms=(32,32,1), so the Y workgroup count is CEIL_DIV(2703360, 32) = 84480, which exceeds the device's maxComputeWorkGroupCount[1] = 65535. The dispatch-limit assertion fires and the process SIGABRTs.

Logs / error messages / stack trace

GGML_ASSERT: .../ggml/src/ggml-vulkan/ggml-vulkan.cpp:8177:
wg0 <= ctx->device->properties.limits.maxComputeWorkGroupCount[0] &&
wg1 <= ctx->device->properties.limits.maxComputeWorkGroupCount[1] &&
wg2 <= ctx->device->properties.limits.maxComputeWorkGroupCount[2] failed

with a diagnostic print added just before the assert:

ggml_vk_dispatch_pipeline: dispatch exceeds device limits:
pipeline matmul_f32_f32_s
wg=(1,84480,1)
elements=(1,2703360,1)
wg_denoms=(32,32,1)
max_wg=(4294967295,65535,65535)

SIGABRT: abort
PC=0x7f6afbc9a17c m=7 sigcode=...
signal arrived during cgo execution
Context from the same run:
[INFO] image.cpp:516 - get_learned_condition completed, taking 18.32s
[INFO] image.cpp:853 - generating image: 1/1 - seed 1502861482
[INFO] lora.hpp:982 - (512 / 512) LoRA tensors have been applied, lora_file_path = .../krea2_identity_edit_v1_2.safetensors
ggml_vk_dispatch_pipeline: dispatch exceeds device limits: ...

Additional context / environment details

• OS: Arch Linux, Mesa 26.2.2-arch1.1, Vulkan 1.4.354 (RADV NAVI31), CPU AMD Ryzen 9 7900X.
• Trigger: any krea2 edit that includes reference images produces a very long conditioning sequence; 2 refs at 640×960 gave n = 2703360. Single-ref edits did not trigger it.
• Root cause: ggml_vk_guess_matmul_pipeline() (and the _id variant) select a shader purely for tile-size/occupancy and never check maxComputeWorkGroupCount. The large-tile shaders have wg_denoms[1] = 128 (→ 21120 workgroups for the same n), which fits; only the small-tile shader overflows. ggml_vk_matmul already loops to keep the batch/Z dimension under maxComputeWorkGroupCount[2], but m/n are not handled.
• Local workaround (unfiled): add a ggml_vk_matmul_pipeline_fits(ctx, p, m, n) check in both ggml_vk_guess_matmul_pipeline and ggml_vk_guess_matmul_id_pipeline, and fall back to the next larger-tile pipeline when the preferred one would exceed the limits. With that change the exact request above completes normally (conditioning 18.3s, sampling 57.8s, image saved, exit 0).
• The ggml_vk_dispatch_pipeline diagnostic print shown above is my local addition, not in the tree at the stated commit.