[Bug] GGML_ASSERT(wg0 <= maxComputeWorkGroupCount) crash with 2+ LoRAs at >~800k px on AMD Vulkan backend

[Hty031]

Describe the bug

Generating an SDXL image with 2 or more LoRAs applied at resolutions above ~800k total pixels crashes the process with a Vulkan workgroup-count assertion on AMD GPUs (proprietary driver). With 0-1 LoRAs the same resolutions work fine.

Two distinct failure modes are observed:

• Crash: process aborts (connection reset) with GGML_ASSERT(wg0 <= ctx->device->properties.limits.maxComputeWorkGroupCount[0] ...) failed at ggml-vulkan.cpp:8159
• Hang: server becomes unresponsive (GPU appears stalled, no progress, request never returns); only a process kill helps

Environment

• Windows 10, AMD Radeon RX 5700 (RDNA1 / gfx1010), AMD proprietary driver
• Vulkan backend: --backend diffusion=vulkan1,vae=vulkan1,clip=cpu (device 1 = dGPU, device 0 = iGPU)
• Tested on builds: de298c2 (2026-08-12) and master-827-97d2990 (2026-08-19) — both crash identically
• 8GB VRAM, --vae-tiling enabled

Reproduction

sd-server.exe -m <SDXL_q8.gguf> --backend diffusion=vulkan1,vae=vulkan1,clip=cpu --vae-tiling \
  --steps 30 --cfg-scale 5 --sampling-method euler_a --listen-port 1234 --lora-model-dir <lora_dir>

POST /sdapi/v1/txt2img with 2 LoRAs (e.g. any two generic SDXL LoRAs) at 1152x1536:

{"prompt": "1girl", "width": 1152, "height": 1536, "steps": 30, "cfg_scale": 5,
 "sampling_method": "euler_a", "lora": [{"path": "loraA.safetensors", "scale": 1.0},
                                         {"path": "loraB.safetensors", "scale": 1.0}]}

Crash log (stderr):

D:\a\stable-diffusion.cpp\stable-diffusion.cpp\ggml\src\ggml-vulkan\ggml-vulkan.cpp:8159:
GGML_ASSERT(wg0 <= ctx->device->properties.limits.maxComputeWorkGroupCount[0] &&
            wg1 <= ctx->device->properties.limits.maxComputeWorkGroupCount[1] &&
            wg2 <= ctx->device->properties.limits.maxComputeWorkGroupCount[2]) failed

Note: the assertion fires after sampling completes, during the post-sampling workload.

Measured boundary (pixel-count dependent, not aspect-ratio dependent)

LoRA count	Max safe pixels	Verified OK	Verified crash/hang
0-1	~1.77M	1152x1536, 1024x1536	—
2	~786k	768x1024, 1024x768, 512x1536	576x1536 (884k), 832x1152 (958k, hang), 832x1216 (hang), 1024x1024, 896x1280, 1152x1536
4	~614k	640x960	768x1024 (hang)

The boundary is total pixel count, independent of aspect ratio (512x1536 works, 576x1536 crashes).

Root cause analysis

This is the same class of bug as llama.cpp issue #19471 (mul_mat dispatch exceeding maxComputeWorkGroupCount on AMD). The AMD proprietary driver reports maxComputeWorkGroupCount = [65535, 65535, 65535], so CEIL_DIV(elements, wg_denoms) overflows the limit when certain tensor dimensions grow. llama.cpp fixed it in PR #19509 ("vulkan: split mul_mat into multiple dispatches to avoid overflow").

Applying 2+ LoRAs changes the compute graph such that the oversized dispatch occurs at ~800k px; without LoRAs the same resolution stays below the limit.

Expected behavior

No crash / hang regardless of LoRA count, or a graceful fallback (e.g. split dispatches like llama.cpp PR #19509, or chunked dispatch).

Additional notes

• Reported by an AI agent on behalf of a user (no personal information included).
• Happy to provide full logs or run additional tests.