{{ message }}
feat(ggml-org.llamacpp): b10069.1 and b10069.2, and a CI pin that follows the engine - #361
Merged
Conversation
…lows the engine `b10069.1` adds `backend-vulkan`: llama.cpp's Vulkan backend as build-graph edges, 134 vendored shaders compiled by declared actions rather than by a build program looping. `b10069.2` refuses a libc++ toolchain by name -- upstream's ggml-vulkan.cpp destroys a `std::unique_ptr` to an incomplete type, which libc++ rejects by static assertion and libstdc++ accepts. Both mirrors byte-identical (1456b6003dada314..., 36027267 bytes). The CI pin moves 2026.8.27.2 -> 2026.9.6.3. It had drifted about ten releases behind, so this index was validated against an engine no user runs. These entries made the drift visible rather than causing it: their build program calls `mcpp::toolchain_sysroot()` and `mcpp::toolchain_binutils_dir()` (2026.9.5.2+) to hand the ecosystem C library to the second compiler it drives, and `mcpp::cxx_stdlib()` (2026.9.6.3) to make the refusal above possible. Under the old pin the workspace members could not compile it at all. The cost is paid once per move and it is large: the members' caches key on `MCPP_VERSION`, so this run rebuilds every member on every platform -- measured on the previous attempt at twelve shards still cold after fifty minutes. Both revisions therefore land in ONE pin move rather than two, which is also why the `mcpp:plugins` 0.2.1 entry went separately in #360: it needed no pin change, so `select` picked nothing for it. `index.toml` min_mcpp does not move. It states the oldest mcpp able to RESOLVE every descriptor, and all of them parse under both versions; raising it would refuse the whole index to a client on the floor over a build-program API that client may never reach. `b10069` stays published for exactly that case.
The caps were the binding constraint again and the measured table has grown about 50% since they were set. `plan_shards.lua` on this tree reports linux 23925s, macos 16676s, windows 18435s, so `secs / 4200 + 1` asks for 6 / 4 / 5 while the caps clamped to 4 / 2 / 2. Windows at 18435s over two shards is roughly 150 minutes a shard, over the 90-minute job cap before a cold cache is considered at all. Observed rather than predicted. On this PR's pin move three shards were cancelled at exactly 90 minutes: `linux default 0/4`, `linux default 3/4` and `windows default 0/2`. The two linux shards passed on a re-run against the warm registry cache. The Windows one timed out AGAIN at 1h30m13s WITH the cache restored -- the pin change invalidates every member build, and that shard carries godot-cpp-m twice (9.5 and 10 minutes) plus opencv. linux 4 -> 6, windows 2 -> 5. macos stays at 2: it has never been cancelled, so raising it would be a prediction rather than a measurement, and the formula's 4 is there the day it is. The paragraph that set the previous caps is marked superseded rather than deleted, because it records the measurement that was true when it was written.
`plan_shards.lua` takes a PLATFORM and reads one timing table. It has no toolchain dimension, so `linux default` and `linux llvm` were handed an identical split of an identical estimate -- and they are not identical work. The llvm leg resolves a different compiler with no sysroot, and it is the slower of the two. Measured on this PR, with both legs at 6 shards: every `linux default` shard finished, and `linux llvm 5/6` was cancelled at 1h30m16s. The split was right for the leg the table was measured on and wrong for the other one. `lln = ln + 3` is the smallest correct fix. Teaching the planner about toolchains is the larger one and needs a timing table per leg, which CI does not produce yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
b10069.1addsbackend-vulkan: llama.cpp's Vulkan backend as build-graphedges, 134 vendored shaders compiled by declared actions rather than by a build
program looping.
b10069.2refuses a libc++ toolchain by name -- upstream'sggml-vulkan.cpp destroys a
std::unique_ptrto an incomplete type, which libc++rejects by static assertion and libstdc++ accepts. Both mirrors byte-identical
(1456b6003dada314..., 36027267 bytes).
The CI pin moves 2026.8.27.2 -> 2026.9.6.3. It had drifted about ten releases
behind, so this index was validated against an engine no user runs. These
entries made the drift visible rather than causing it: their build program calls
mcpp::toolchain_sysroot()andmcpp::toolchain_binutils_dir()(2026.9.5.2+)to hand the ecosystem C library to the second compiler it drives, and
mcpp::cxx_stdlib()(2026.9.6.3) to make the refusal above possible. Under theold pin the workspace members could not compile it at all.
The cost is paid once per move and it is large: the members' caches key on
MCPP_VERSION, so this run rebuilds every member on every platform -- measuredon the previous attempt at twelve shards still cold after fifty minutes. Both
revisions therefore land in ONE pin move rather than two, which is also why the
mcpp:plugins0.2.1 entry went separately in #360: it needed no pin change, soselectpicked nothing for it.index.tomlmin_mcpp does not move. It states the oldest mcpp able to RESOLVEevery descriptor, and all of them parse under both versions; raising it would
refuse the whole index to a client on the floor over a build-program API that
client may never reach.
b10069stays published for exactly that case.