feat!: upgrade llama.cpp from b10797 to b10817

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

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<nnnn>` 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

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)  

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. |

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=<SOURCE_DIR>

llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java

@@ -10,28 +10,28 @@
  * 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.
  *
- * <p>{@link #LLAMA_CPP_VERSION} is a pure-Java string ({@code "b10797"}) that mirrors the
+ * <p>{@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.</p>
  *
  * <p>For the <em>authoritative</em> value that is baked into the native binary — the build number
- * plus the resolved upstream commit, e.g. {@code "b10797-<commit>"} — call
+ * plus the resolved upstream commit, e.g. {@code "b10817-<commit>"} — 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).</p>
  */
 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"}.
      *
      * <p>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.</p>
      */
-    public static final String LLAMA_CPP_VERSION = "b10797";
+    public static final String LLAMA_CPP_VERSION = "b10817";
 
     // Constants holder — not instantiable.
     private LlamaCppVersion() {}