diff --git a/CHANGELOG.md b/CHANGELOG.md index 4a05c41e..c1f0382e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -58,7 +58,7 @@ from version 5.0.0 onward. Pre-fork releases (`1.x`–`4.2.0`) were authored by where the backend cannot provide it, `OFF` disables it. ### Changed -- **llama.cpp `b10731` → `b10797`.** No project-source change: every header move in the range is +- **llama.cpp `b10731` → `b10817`.** No project-source change: every header move in the range is additive or a **widening** const-qualification, and the server wire contract is byte-identical (request-field set, `set_hard_limits` bounds and response keys all verified mechanically, which is the check that catches the contract-behind-a-stable-signature breaks a header diff cannot see). @@ -90,6 +90,21 @@ from version 5.0.0 onward. Pre-fork releases (`1.x`–`4.2.0`) were authored by `llama_build_info()` from `common/build-info.cpp` instead — verified by the smoke test that cross-checks the pin against the linked binary. + The final `b10797` → `b10817` step touches seven files across the paths this project links + against, `+12 / −13` in total, and none of them needs a source change here: + + - `common/build-info.h` gains an optional `FILE *` on `llama_print_build_info` (llama.cpp + #28322) — a **default argument**, so every existing one-argument call still compiles. The + project does not call it; it uses `llama_build_info()`, which is unchanged. + - `ggml/include/ggml-backend.h` **removes** `ggml_backend_op_alloc_size_may_expand` (the ggml + sync, #28379). No source here references it, so the removal is inert — checked, not assumed, + because a deletion from a public header is the one shape that breaks a build silently. + - `tools/mtmd/mtmd.cpp` corrects Gemma-4V causal-attention handling for the E2B/E4B embedding + sizes and `clip.cpp` raises an image-token limit (#28335) — both model behaviour inside + upstream translation units, no API movement. + - The remaining three are upstream's own version bump, a `LLAMA_VERSION_MINOR` change and a + BoringSSL pin that only applies with `LLAMA_BUILD_BORINGSSL`, which this project leaves off. + - **llama.cpp `b10682` → `b10731`.** One project-source change came out of it, and it is the kind a header diff does not surface: upstream renamed `--tensor-read-lazy` to `-lzm` / `--lazy-mode` (env `LLAMA_ARG_TENSOR_READ_LAZY` → `LLAMA_ARG_LAZY_MODE`) **with no alias**. The binding emitted diff --git a/CLAUDE.md b/CLAUDE.md index cd7905e4..e78d8186 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,7 +6,7 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co Java bindings for [llama.cpp](https://github.com/ggerganov/llama.cpp) via JNI, providing a high-level API for LLM inference in Java. The Java layer communicates with a native C++ library through JNI. -Current llama.cpp pinned version: **b10797** +Current llama.cpp pinned version: **b10817** ## Upgrading CUDA Version @@ -490,7 +490,7 @@ needs no extra step here, `build-webui` re-reads the tag and rebuilds the matchi ships no UI): ```bash # needs node/npm + network; embed.cpp is plain C++17 (no npm) -git clone --depth 1 --branch b10797 https://github.com/ggml-org/llama.cpp /tmp/lc +git clone --depth 1 --branch b10817 https://github.com/ggml-org/llama.cpp /tmp/lc ( cd /tmp/lc/tools/ui && npm ci && npm run build \ && ( cd dist && find . -type f -not -path './_gzip/*' \ | while read -r f; do mkdir -p "_gzip/$(dirname "$f")"; gzip -9 -c "$f" > "_gzip/$f"; done ) \ @@ -530,7 +530,7 @@ cache lives in **Depot Cache** over sccache's **WebDAV** backend: - `SCCACHE_WEBDAV_TOKEN: ${{ secrets.DEPOT_TOKEN }}` — a Depot **organization** token, stored as the repo secret **`DEPOT_TOKEN`**. -Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10797`), the +Because `sccache` is **content-addressed** and llama.cpp is pinned (`GIT_TAG b10817`), the ~280 upstream object files are byte-identical every run, so a warm cache recompiles only the *changed* files. Depot's cache is **shared across all branches** (unlike GitHub's per-branch `actions/cache`), so every branch builds incrementally; a `b` version bump @@ -1451,7 +1451,7 @@ ctest --test-dir build --output-on-failure -R "ResultsToJson" #### Upstream source location (in CMake build tree) -llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10797`. +llama.cpp is fetched via CMake FetchContent, pinned to `GIT_TAG b10817`. **GoogleTest** is a separate `BUILD_TESTING`-only FetchContent (`GIT_TAG v1.17.0`), used solely by the `jllama_test` C++ unit-test binary — not by the shipped library, and not coupled to the diff --git a/README.md b/README.md index 7acf2aa3..1527ba8b 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ **Build:** ![Java 8+](https://img.shields.io/badge/Java-8%2B-informational) ![Platform](https://img.shields.io/badge/Platform-Linux%20%7C%20macOS%20%7C%20Windows%20%7C%20Android-lightgrey) -[![llama.cpp b10797](https://img.shields.io/badge/llama.cpp-%23b10797-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10797) +[![llama.cpp b10817](https://img.shields.io/badge/llama.cpp-%23b10817-informational)](https://github.com/ggml-org/llama.cpp/releases/tag/b10817) [![JPMS](https://img.shields.io/badge/JPMS-modular%20JAR-25A162)](https://openjdk.org/projects/jigsaw/) ![JUnit](https://img.shields.io/badge/tested%20with-JUnit6-25A162) [![JSpecify](https://img.shields.io/badge/JSpecify-1.0.0%20%40NullMarked-25A162)](https://jspecify.dev) diff --git a/docs/history/llama-cpp-breaking-changes.md b/docs/history/llama-cpp-breaking-changes.md index 21cbd864..c294f5e7 100644 --- a/docs/history/llama-cpp-breaking-changes.md +++ b/docs/history/llama-cpp-breaking-changes.md @@ -690,3 +690,5 @@ Used during `llama.cpp` version bumps: when upgrading, scan this file from the r | b10731–b10792 | patches + upstream verification | **All 8 patches still apply, and 3 of their 42 target files were in the range** — `common/arg.cpp` and `tools/mtmd/mtmd-cli.cpp` (both `0001`) and `tools/server/server-context.cpp` (`0002`/`0003`/`0010`) — so this was not a no-op intersection and had to be proven by running the applier, not by reasoning about it. Fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON` through the real `FetchContent` path: configure clean, stamp written at `head c5a5535e6ebc2e74ab0e3f1b249d7d989aba26a2`, all eight hashes recorded. `0010` was additionally re-checked **by hand** against the rule in `CLAUDE.md` (the fail-loud applier can detect "does not apply" but never "upstream already fixed this, drop me"): `get_res_model_info()` in b10792 still emits `{"vocab_type", meta.model_vocab_type}` with no cast, so the patch stays. `0001` likewise: `common_params_parse_main` still appears nowhere in `b10792:common/arg.h`, and the `#ifdef _WIN32` `argv = utf8.ptrs.data()` override is still in `arg.cpp` — upstream has not adopted [#26416](https://github.com/ggml-org/llama.cpp/issues/26416). **Chunking note:** the runbook's 100 KiB-per-step rule was **not** applied to this range, deliberately. The full `b10731...b10792` diff is 4.19 MB, but `docs/ops/Hexagon.csv` alone is 19 792 generated lines and the GPU backends (`ggml-opencl`, `ggml-hexagon`, `ggml-metal`, `ggml-cuda`, `ggml-sycl`) account for most of the rest — both outside the review surface the rule exists to bound (`ggml/src/**` is on the "safe to skip" list). Across `common/`, `include/`, `tools/server/`, `tools/mtmd/` and `ggml/include/` the range is **35 files, +758 / −175**, reviewable in one pass; chunking it would have produced ~44 commits for one bump without adding a single line of review. The size figures are recorded here so the deviation is auditable rather than silent. | | b10792–b10797 | `ggml/src/ggml-cpu/arch/s390/quants.c` (**#28332: `q5_1` used an uninitialized `v_acc`**), `ggml/src/ggml-sycl/**` (#27610 rms_norm+mul+add / add+add fusion, #26863 `GGML_SYCL_ENABLE_MKL_FA` made a global), `src/llama-hparams.{h,cpp}` + `src/llama-model.cpp` + `src/llama-model-loader.cpp` (**#28323: new internal `n_expert_used_max()`**), `src/CMakeLists.txt` + new `src/llama-version.h.in` (**#28278: stop rebuilding the whole source tree on every commit**), `src/llama.cpp`, `tests/test-backend-ops.cpp`, `docs/backend/SYCL.md` | **No project-source change, and this time the review surface is literally empty**: the range touches **zero** files under `common/`, `include/`, `tools/server/`, `tools/mtmd/`, `ggml/include/` or the top-level `CMakeLists.txt`. Server contract re-checked anyway and byte-identical (request fields, response keys). Two entries are still worth recording. **(1)** #28332 is a **big-endian correctness fix on a platform this project ships in the default JAR**: `ggml_vec_dot_q5_1_q8_1`'s s390x path accumulated into an uninitialized `v_acc`, so `Q5_1` inference on IBM Z could return garbage. The `build-linux-s390x` job cross-builds and runs the C++ suite under `qemu-user`, but that suite covers *our* endian-sensitive layer (`tts_wav.hpp`, the JSON/token transforms), not ggml's kernels — so this is precisely the class of bug the job cannot see and upstream has to fix. **(2)** #28278 moves `LLAMA_VERSION`/`LLAMA_COMMIT` out of `target_compile_definitions(llama PRIVATE ...)` into a `configure_file`-generated `src/llama-version.h`. That is the one change in the range that could plausibly have reached the project, since `NativeLibraryLoadSmokeTest.nativeBuildInfoMatchesPinnedVersionConstant` asserts the pin against the linked binary — but `jllama.cpp` reads `llama_build_info()` from `common/build-info.cpp`, a different mechanism, and the test passes at b10797. Verified rather than reasoned about. | | b10792–b10797 | patches + upstream verification | **Zero intersection with the patch set, established mechanically.** The 42 files the eight patches touch were intersected against the range's 18 changed files: empty, so no patch context can have moved. Confirmed by running the applier for real anyway: fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON`, configure clean, stamp at `head 832fd6f1741ad9f66fb2a785002396700666595a`, all eight hashes recorded. **This step needed no chunking decision**: the full `b10792...b10797` diff is 46 KB across 5 commits, comfortably inside the runbook's 100 KiB threshold, so it is a straight bump by the rule rather than in spite of it. | +| b10797–b10817 | `common/build-info.{h,cpp.in}` (**#28322: `llama_print_build_info` gains a `FILE *` stream**), `ggml/include/ggml-backend.h` (**REMOVES `ggml_backend_op_alloc_size_may_expand`**, via the #28379 ggml sync), `tools/mtmd/mtmd.cpp` + `clip.cpp` (**#28335: gemma4 vision handling; image-token limit 40/280 → 70/1120**), `CMakeLists.txt` (`LLAMA_VERSION_MINOR` 3 → 4, #28386), `vendor/cpp-httplib/CMakeLists.txt` (BoringSSL pin, #28354). Everything else in the range is GPU-backend work (`ggml-opencl` +940 and a new 871-line Adreno SDPA kernel, Metal fa-vec tunings for M3/M3 Max, SYCL memtrace), a new model architecture (`src/models/hy-v4.cpp`, #28127), upstream CI and the WebUI. | **No project-source change.** The whole review surface is **7 files, +12 / −13**. Two entries needed checking rather than skimming. **(1)** `llama_print_build_info(const char *)` became `llama_print_build_info(const char *, FILE * = stderr)` — a **default argument**, so any existing one-argument call still compiles; the project does not call it at all and reads `llama_build_info()`, which is untouched. Worth noting anyway because `build-info` is what `NativeLibraryLoadSmokeTest` cross-checks against the pin, and this is the second consecutive range to move that file (b10792–b10797 carried #28278). **(2)** the **removal** of `ggml_backend_op_alloc_size_may_expand` from a public ggml header — a deletion is the one shape that breaks a build with no diff hunk to notice, so the project source was grepped for it: zero references, in `src/main/cpp` and `src/test/cpp` alike. The server contract was re-checked and is byte-identical (request fields, `set_hard_limits` bounds, response keys in both emit forms); `tools/server/` has no `.cpp`/`.h` change in the range at all. | +| b10797–b10817 | patches + upstream verification | **Zero intersection with the patch set.** The 42 files the eight patches touch were intersected against the range's changed-file list: empty, so no patch context can have moved. The applier was run for real anyway — fresh `rm -rf build && cmake -B build -DBUILD_TESTING=ON`, configure clean, stamp at `head cd8cdf397dc21d986e69069ce2180651d693fdff`, all eight hashes recorded. **Chunking:** the full diff is 307 KB, over the runbook's 100 KiB threshold, but excluding `ggml/src/**`, `tools/ui/**`, `docs/**`, `.github/**` and `conversion/**` — every one of them outside the review surface the rule exists to bound — it is **68 KB, under the threshold**. Same call as the previous bump, and this time the excluded-diff figure alone justifies it. **This range does NOT address the macOS-15 regression introduced at b10797** (see the two rows above): `src/llama-model-loader.cpp` is untouched here and `hparams.n_expert_used_max()` — the prime suspect from #28323 — is still called at both b10797 sites. Expect `Java Tests macOS 15 arm64` to stay red until that is bisected. | diff --git a/llama/CMakeLists.txt b/llama/CMakeLists.txt index 079e6697..d01e3355 100644 --- a/llama/CMakeLists.txt +++ b/llama/CMakeLists.txt @@ -173,7 +173,7 @@ set(LLAMA_BUILD_APP OFF CACHE BOOL "" FORCE) FetchContent_Declare( llama.cpp GIT_REPOSITORY https://github.com/ggerganov/llama.cpp.git - GIT_TAG b10797 + GIT_TAG b10817 PATCH_COMMAND ${CMAKE_COMMAND} -DPATCH_DIR=${CMAKE_CURRENT_SOURCE_DIR}/patches -DLLAMA_SRC= diff --git a/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java b/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java index b65db948..478c604a 100644 --- a/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java +++ b/llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java @@ -10,13 +10,13 @@ * library was compiled against, exposed as a compile-time constant so callers can render a badge or * emit a startup log line without loading the native library. * - *

{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10797"}) that mirrors the + *

{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10817"}) that mirrors the * {@code GIT_TAG} in {@code llama/CMakeLists.txt}. It is available even when {@code libjllama} is * absent (pure-Java checkout, before {@code System.load}), which is what makes it suitable for a * lightweight version badge in Android or other UIs.

* *

For the authoritative value that is baked into the native binary — the build number - * plus the resolved upstream commit, e.g. {@code "b10797-"} — call + * plus the resolved upstream commit, e.g. {@code "b10817-"} — call * {@link net.ladenthin.llama.LlamaModel#getLlamaCppBuildInfo()} instead; that reads llama.cpp's own * {@code build-info} through JNI and therefore cannot drift from the compiled library (but requires * the native library to be loaded).

@@ -24,14 +24,14 @@ public final class LlamaCppVersion { /** - * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10797"}. + * The pinned llama.cpp release tag this library was built against, e.g. {@code "b10817"}. * *

Kept in lockstep with {@code GIT_TAG} in {@code llama/CMakeLists.txt} — see the * "Upgrading/Downgrading llama.cpp Version" checklist in {@code CLAUDE.md}. This is the * compile-time pin; use {@link net.ladenthin.llama.LlamaModel#getLlamaCppBuildInfo()} for the * value actually linked into the native binary.

*/ - public static final String LLAMA_CPP_VERSION = "b10797"; + public static final String LLAMA_CPP_VERSION = "b10817"; // Constants holder — not instantiable. private LlamaCppVersion() {}