Skip to content

fix: make parameter loading backend-aware - #1828

Merged
leejet merged 1 commit into
leejet:masterfrom
happyyzy:agent/sdcpp-q4-loader-getrows-fix
Jul 29, 2026
Merged

fix: make parameter loading backend-aware#1828
leejet merged 1 commit into
leejet:masterfrom
happyyzy:agent/sdcpp-q4-loader-getrows-fix

Conversation

@happyyzy

Copy link
Copy Markdown
Contributor

Summary

Fix two backend correctness issues in model loading:

  • serialize non-host backend uploads while keeping file I/O and host conversion parallel
  • carry parameter usage ops into ModelManager, select a compatible buffer with supports_op, and enable CPU fallback only for unsupported graph nodes

This follows llama.cpp's per-op buffer selection. It adds no model, tensor-name, or shape special cases and does not modify ggml.

Previously loader workers entered the same backend upload path concurrently, while Q4_0 token embeddings were placed in an OpenCL SoA buffer that rejects GET_ROWS(Q4_0).

Image evidence

Tested on Adreno 830 with OpenCL, GGML_OPENCL_SOA_Q, Adreno kernels, Q4_0 DP4A GEMM, and direct VAE convolution. The image runs used ggml from llama.cpp commit 7e1e28cae36d41fe7bbe9dae7c9625de6565c063.

Case Before After
Flux.2 Klein Q4_0, 512x512 Klein before Klein after
Z-Image Turbo Q4_0, 512x512 Z-Image before Z-Image after

The unpatched default four-thread load aborts in clCreateSubBuffer. The before images use -t 1 only to isolate the independent incompatible-buffer error. Patched runs use the default four loader threads.

Reproduction commands

export GGML_OPENCL_Q4_0_DENSE_DP4A=1

# Flux.2 Klein, before
./bin/sd-cli \
  --diffusion-model "$KLEIN_Q4_0_GGUF" \
  --llm "$QWEN_3_4B_Q4_0_GGUF" \
  --vae "$FLUX2_VAE_SAFETENSORS" \
  -p "a lovely cat" --cfg-scale 1.0 --steps 4 --seed 42 \
  -W 512 -H 512 --vae-conv-direct -t 1 -o klein_before.png -v

# Flux.2 Klein, after
./bin/sd-cli \
  --diffusion-model "$KLEIN_Q4_0_GGUF" \
  --llm "$QWEN_3_4B_Q4_0_GGUF" \
  --vae "$FLUX2_VAE_SAFETENSORS" \
  -p "a lovely cat" --cfg-scale 1.0 --steps 4 --seed 42 \
  -W 512 -H 512 --vae-conv-direct -o klein_after.png -v

# Z-Image Turbo, before
./bin/sd-cli \
  --diffusion-model "$Z_IMAGE_TURBO_Q4_0_GGUF" \
  --llm "$QWEN_3_4B_Q4_0_GGUF" \
  --vae "$Z_IMAGE_AE_SAFETENSORS" \
  -p "a lovely cat" --cfg-scale 1.0 --steps 8 --seed 42 \
  -W 512 -H 512 --vae-conv-direct -t 1 -o zimage_before.png -v

# Z-Image Turbo, after
./bin/sd-cli \
  --diffusion-model "$Z_IMAGE_TURBO_Q4_0_GGUF" \
  --llm "$QWEN_3_4B_Q4_0_GGUF" \
  --vae "$Z_IMAGE_AE_SAFETENSORS" \
  -p "a lovely cat wearing black sunglasses, studio photo" \
  --cfg-scale 1.0 --steps 4 --seed 42 \
  -W 512 -H 512 --vae-conv-direct -o zimage_after.png -v

Checks

git diff --check origin/master..HEAD

cmake -S . -B build-pr -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_OPENCL=ON \
  -DGGML_OPENCL_USE_ADRENO_KERNELS=ON \
  -DGGML_OPENCL_EMBED_KERNELS=ON

cmake --build build-pr --target sd-cli -j

The Android/OpenCL sd-cli build also passes against the repository's pinned ggml@eced84c8.

Checklist

@happyyzy
happyyzy marked this pull request as ready for review July 29, 2026 03:22
@leejet
leejet merged commit 2993b7f into leejet:master Jul 29, 2026
8 of 9 checks passed
@happyyzy happyyzy mentioned this pull request Jul 29, 2026
dbrain added a commit to dbrain/hbd-longcat-avatar.cpp that referenced this pull request Aug 2, 2026
…device runs

Upstream leejet#1828 added GGMLRunner::graph_requires_backend_fallback(), which scans
every node with supports_op and creates a ggml_backend_sched the moment one
answers no, so the node can fall back to the CPU backend. That is correct
upstream, where supports_op is truthful.

It is not safe here. This fork's CUDA supports_op is deliberately conservative in
several places -- it declines shapes the backend can in fact execute -- and that
was FREE for as long as a single-device run built no scheduler and therefore
never asked. Turning the probe on makes every one of those rejects load-bearing.
Two different services died on two different asserts, both on the first real
render after the upstream merge:

  LTX 2.3   nvfp4-CLEAN @1920x1088x97
            ggml_backend_sched_split_graph:
            GGML_ASSERT(*cur_backend_id != -1)
            MUL_MAT, transformer_blocks.0.attn1.to_gate_logits.weight bf16
            [4096,32] against the F16 residual stream f16 [4096,26520] -> f32.
            CUDA declined it (that specific lie is now fixed in ggml-cuda.cu) and
            the CPU backend does not implement BF16 x F16, so nothing could take
            the node.

  LTX-2B    ggml-cuda.cu:
            GGML_ASSERT(buf->buft == ggml_backend_cuda_buffer_type(...))
            the scheduler placed a node off-CUDA while this runner stages its own
            params straight to CUDA, so the buffer types disagreed.

The second one is the point: fixing individual supports_op lies does not close
this, it just moves which model fires first. Auditing every supports_op path
across six model families for truthfulness is unbounded work and is not a merge
task. Single-device-without-a-scheduler is what all six services are validated
against and what shipped before this merge, so that behaviour is restored.

The helper is kept, unused, so the next upstream merge does not read as a
conflict here. If CPU fallback is ever wanted, the prerequisite is a truthful
supports_op -- not re-enabling this call.

Smoke-tested across the fleet after the change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants