QVAC-19998 feat(ltx): full-GPU LTX-2.3 video support (Metal)

[aegioscy]

Summary

Splits the LTX / custom-ggml delta out of the 2026-06-04 fork base.

2026-06-04 (base) = upstream 1f9ee88 + the 5 general, upstream-ggml-compatible patches: vcpkg port infra, Flux qkv assert, ESRGAN device API, upscaler defaults, Wan I2V VAE tiling bypass. Its ggml submodule stays at stock leejet/ggml 0ce7ad3.

This PR adds the 6 commits that depend on / switch to the unified qvac ggml:

• feat: use fused Flux RoPE when available — requires GGML_OP_ROPE_FLUX (not in stock leejet ggml); bumps submodule to qvac-ext-ggml
• chore: remove ggml git submodule — use vcpkg SD_USE_SYSTEM_GGML
• fix: remove ggml-impl.h include — symbols are in public ggml.h
• ggml_graph_cut: use public ggml_graph_leaf/n_leafs/add_leaf API
• cli: default preferred_gpu_backend to GPU — fixes the LTX pipeline running on CPU
• cmake: add /bigobj for MSVC — build fix for the larger LTX/system-ggml objects

LTX-2.3 model support itself comes from upstream; these are the qvac-side build/packaging reconciliation + the custom-ggml dependency.

Notes

• Pure history reorganization: the 2026-06-04-ltx tip (df47d5e) is unchanged and byte-for-byte identical to the original fork tip.
• The fused-RoPE submodule bump that previously leaked onto the base (pointing the leejet-URL submodule at qvac-ext-ggml@c40a0fc) now lives here instead.

Test plan

• CI green on 2026-06-04-ltx
• Build sd-cli (Release, Metal) against vcpkg system ggml
• Smoke-test LTX-2.3 T2V generation

[dev-nid]

The default build path looks broken on this branch. Verified on a clean checkout of df47d5e:

cmake .. with default flags (the flow docs/build.md documents) — exit 1:

CMake Error at CMakeLists.txt:312 (add_subdirectory):
add_subdirectory given source "ggml" which is not an existing directory.
-- Configuring incomplete, errors occurred!
The PR removes the ggml submodule, but SD_USE_SYSTEM_GGML still defaults to OFF and CMakeLists.txt:312 still does add_subdirectory(ggml). On 2026-06-04 the leejet submodule populates ggml/ so the default works; after this PR it doesn't. There are also no vcpkg port files in-tree on either branch, so I assume the qvac-ext-ggml port lives in a separate overlay.

Questions:

Is consuming this repo directly (without the vcpkg overlay) unsupported on this branch? If yes, can we either flip SD_USE_SYSTEM_GGML default to ON, or replace the add_subdirectory(ggml) fallback with a message(FATAL_ERROR ...) pointing users at -DSD_USE_SYSTEM_GGML=ON + the qvac-ext-ggml package?
Should docs/build.md be updated here? It still tells users to git clone --recursive / git submodule update, which no longer pulls a ggml tree.
add_definitions(-DGGML_MAX_NAME=128) is guarded by if (NOT SD_USE_SYSTEM_GGML), so it never applies on this branch. Is the qvac-ext-ggml package built with GGML_MAX_NAME=128? If not, long tensor names get silently truncated vs. before.

[aegioscy]

Thanks @dev-nid — all four points addressed in 6a13b9c:

1. Default build path. SD_USE_SYSTEM_GGML now defaults to ON. After the submodule removal, system/vcpkg ggml is the only supported path on this branch, so a plain cmake .. -DCMAKE_TOOLCHAIN_FILE=<vcpkg>/scripts/buildsystems/vcpkg.cmake now resolves ggml::ggml and configures cleanly.

2. add_subdirectory(ggml) fallback. Replaced. If someone explicitly passes -DSD_USE_SYSTEM_GGML=OFF and there is no ggml/ submodule, CMake now fails with a clear FATAL_ERROR pointing at the qvac-ext-ggml vcpkg port + toolchain, instead of the confusing "source ggml is not an existing directory" error. The system path also emits a clear error if find_package(ggml) fails.

3. Direct consumption / docs. Yes — consuming this repo directly is supported via the qvac-ext-ggml vcpkg port (not a vendored submodule). docs/build.md updated: dropped the --recursive / git submodule update instructions and documented the system/vcpkg ggml workflow.

4. GGML_MAX_NAME=128 — no mismatch. The qvac-ext-ggml port builds with -DGGML_MAX_NAME=128 and exports it as a PUBLIC/INTERFACE compile definition on ggml::ggml-base (its ggml-config.cmake appends INTERFACE_COMPILE_DEFINITIONS GGML_MAX_NAME=128). So every consumer linking ggml::ggml inherits 128 automatically — including sd.cpp's own translation units, even though the in-tree add_definitions(-DGGML_MAX_NAME=128) is skipped under system ggml. That add_definitions now only applies to non-system builds.