Mesa 26.1.7 doubles Vulkan throughput on Intel Arc B580 (Battlemage) — 30 → 67 tok/s

[guidov]

Mesa 26.1.7 doubles llama.cpp Vulkan throughput on Intel Arc B580 (Battlemage)

Swapping only the Intel Vulkan driver — Mesa 26.0.8 → 26.1.7 — took Ollama from ~30 to ~67 tok/s on an Arc B580. Same GPU, same kernel, same model, same context,
same quantization. Nothing else on the machine changed.

The kernel turned out to be irrelevant, which was the opposite of what I expected going in.

Charts and full methodology: https://claude.ai/code/artifact/858caefa-9680-4bda-a038-f527065df867

Results

400-token decode, three seeds per driver, throughput from Ollama's eval_count / eval_duration.

Model	Architecture	ctx	Mesa 26.0.8	Mesa 26.1.7	Gain
gemma4:latest (E4B, Q4_K_M)	per-layer embeddings, 5:1 SWA	131072	30.25	66.99	2.21×
qwen3:8b	dense, standard GQA	8192	29.79	61.01	2.05×

decode throughput, tok/s (higher is better)

gemma4  Mesa 26.0.8  ███████████████████·························  30.25
gemma4  Mesa 26.1.7  ██████████████████████████████████████████··  66.99
qwen3   Mesa 26.0.8  ███████████████████·························  29.79
qwen3   Mesa 26.1.7  ██████████████████████████████████████······  61.01

Individual runs:

gemma4  26.0.8 : 30.55, 30.25, 29.95
gemma4  26.1.7 : 67.09, 67.30, 66.59
qwen3   26.0.8 : 29.61, 29.89, 29.87
qwen3   26.1.7 : 60.35, 61.33, 61.36

The two models share almost nothing structurally — gemma4 E4B keeps ~5.9 GB of per-layer embedding weights in host RAM by design and caps 35 of its 42 layers at a 51
2-token sliding window; qwen3:8b is a conventional dense model fully resident on the GPU. Both roughly double, so this isn't an artifact of one architecture.

Context scaling: a cliff on the old driver that disappears

On 26.0.8, gemma4 held ~34 tok/s up to 32k context and then stepped down to ~30 and stayed there. On 26.1.7 the curve is flat to the model's full window.

num_ctx	26.0.8	26.1.7
4,096	34.41	67.39
32,768	34.45	66.47
49,152	29.61	66.99
131,072	30.18	67.08

Caveat: qwen3 was flat on both drivers across 4k–32k (29.87→29.89 and 61.27→61.34), but its KV cache grows linearly with no sliding-window cap, so contexts past 32
k exceed 12 GB. The cliff was only observed on one model and may not generalize.

The kernel made no difference

This began as a kernel experiment — I'd read that Battlemage improvements needed 7.2. Mainline 7.2.0 vs Ubuntu 7.0.0-30, Mesa 26.1.7 on both, gemma4 at 128k:

Kernel	tok/s
7.0.0-30-generic (Ubuntu)	66.86
7.2.0-070200 (mainline)	67.00

+0.21%, well inside noise. The gain is entirely userspace; xe on 7.0 submits to Battlemage just as well. Pairing 26.1 with a newer kernel was not necessary.

Setup

• Intel Arc B580 (BMG G21), 12 GB, xe driver
• Ubuntu 26.04, kernel 7.0.0-30-generic
• Ollama 0.33.0 (ships libggml-vulkan.so; Vulkan enabled by default on discrete GPUs)
• Mesa 26.0.8-1ubuntu0.3 (Ubuntu archive) vs 26.1.7kisak1r (kisak-mesa PPA)
• B580 drives no displays (AMD 760M iGPU runs the desktop), so 10,955 MiB free for compute in every run

Method

Both drivers were tested through a second Ollama instance on port 11435, identical except VK_DRIVER_FILES pointing at a different ICD. System Mesa was never modifi
ed.

• Full GPU offload confirmed from the loader log each run (43/43 gemma4, 37/37 qwen3)
• Free VRAM verified identical (10,955 MiB) before each measurement
• Instances stopped with SIGTERM and drained to zero llama-server processes between cases

Trap worth repeating: SIGKILL on ollama serve orphans its llama-server child, which keeps holding VRAM. The next instance then sees less free memory and sil
ently partial-offloads — one early run gave 22/43 layers and 13.5 tok/s with no error anywhere. Always check the offload line rather than trusting the number.

What this doesn't establish

I could not identify the mechanism. Four extensions are new in 26.1.7 on this device:

VK_NV_cooperative_matrix2
VK_EXT_present_timing
VK_EXT_device_address_binding_report
VK_KHR_internally_synchronized_queues

VK_NV_cooperative_matrix2 was the obvious suspect, since ggml-vulkan has a dedicated coopmat2 matmul path. It isn't the cause — running 26.1.7 with GGML_VK_DI SABLE_COOPMAT2=1 gave 67.5 tok/s, unchanged. Vulkan API level also moved 1.4.335 → 1.4.354.

Other limits:

• One machine, one GPU. Untested on A-series, other Battlemage SKUs, or iGPUs.
• Two models, both quantized. No fp16 or MoE runs.
• Prefill was not the focus; it sat near 136 tok/s on both drivers and barely moved.
• Mesa 26.1.x was not bisected, so the change could have landed anywhere in that series.

If anyone knows what changed in ANV between 26.0 and 26.1 that would produce this, I'd like to hear it.

Testing it without touching system Mesa

A newer ANV can be dropped into a private prefix and handed to one process via VK_DRIVER_FILES, leaving the desktop driver alone:

# extract the driver only, no install
dpkg-deb -x mesa-vulkan-drivers_26.1.7~kisak1~r_amd64.deb prefix/

# ICD pointing at the extracted .so by absolute path
cat > icd.json <<'EOF'
{"ICD":{"api_version":"1.4.354",
 "library_path":"/opt/mesa-26.1.7/lib/libvulkan_intel.so"},
 "file_format_version":"1.0.1"}
EOF

# confirm which driver actually loads
VK_DRIVER_FILES=$PWD/icd.json vulkaninfo --summary | grep driverInfo

# point only ollama at it, via a systemd drop-in
systemctl edit ollama
# Environment="VK_DRIVER_FILES=/opt/mesa-26.1.7/share/vulkan/icd.d/intel_icd.json"

Check driverInfo before trusting any result. An empty or mistyped path falls back to the system driver silently, and then you're benchmarking nothing. That happene
d to me once — an install script copied the system driver into a directory named for the new one, and only the vulkaninfo check caught it.

[N0tPasquy]

Independent Replication & Extension: Mesa 26.2.3, Desktop Environment, and 14B Scaling

Thanks for this write-up! I was able to independently replicate your findings and test a few additional real-world scenarios on an Arc B580 (BMG G21, 12 GB) using the newer Mesa 26.2.3 via the kisak-mesa PPA on Ubuntu 26.04.

Here is the data confirming the performance jump, along with observations on shader compilation and 7B vs 14B scaling.

---

Hardware & Environment

• GPU: Intel Arc B580 Founder Edition (12 GB VRAM, xe kernel driver)
• CPU: Intel Core i5-14400F (no iGPU)
• OS: Ubuntu 26.04 (Kernel 7.2.6-070206-generic)
• Desktop / Display: GNOME / Wayland — GPU drives the main display (~700–900 MiB VRAM used by desktop compositor, unlike OP's headless setup)
• Stack: Ollama (Vulkan / libggml-vulkan.so), Mesa 26.2.3-kisak

---

Replication of Original Models (eval rate / decode)

Model	Context	Mesa 26.0.8 (OP)	Mesa 26.1.7 (OP Headless)	Mesa 26.2.3 (My Test, Display Attached)	Status
gemma4:latest (E4B, Q4_K_M)	4096	30.25 tok/s	66.99 tok/s	61.49 tok/s (sustained: 59.82 tok/s)	Replicated (~2x gain)
qwen3:8b	4096	29.79 tok/s	61.01 tok/s	47.15 tok/s (long 1770-token run)	Replicated (+58%)

Note on Qwen3 throughput: My run was evaluated across a sustained generation of 1774 tokens with GNOME compositor overhead, which explains the delta vs OP's 400-token headless test.

---

SPIR-V Shader Compilation Overhead (Cold vs Warm Cache)

On gemma4, the first inference run exhibited a noticeable delay during prompt evaluation due to driver-level shader compilation:

• Cold cache (Run 1): prompt eval: 5.44s (9.00 tok/s)
• Warm cache (Run 2): prompt eval: 181.5 ms (269.93 tok/s) — ~30x faster TTFT

Anyone benchmarking ANV on Battlemage should ensure they run a warm-up prompt first to avoid mistaking shader compilation latency for compute regression.

---

Extending to Coding Models: qwen2.5-coder (7B vs 14B)

I also tested coding workloads to check how memory bandwidth and compute scale on Battlemage up to the 12 GB VRAM limit. Both ran with 100% layer offload on GPU:

Model	Size	Prompt Eval (Warm)	Decode Throughput	VRAM Status
qwen2.5-coder:7b	~4.7 GB	301.04 tok/s	58.34 tok/s	~5.3 GB total footprint
qwen2.5-coder:14b	~9.0 GB	432.72 tok/s	31.65 tok/s	~10.1 GB footprint (fits comfortably)

Takeaways:

1. Clean Bandwidth Scaling: Moving from 7B to 14B cut the decode speed almost exactly in half (1.84x factor, 58.34 -> 31.65 tok/s), showing linear memory bandwidth saturation with no weird driver bottlenecks.
2. 14B is very usable: 31.65 tok/s makes 14B coding models completely practical for daily interactive local development on an entry-level GPU under Linux.

Mesa 26.1+ is definitely a hard requirement for anyone running local LLMs on Battlemage.

[guidov]

Nice!

…

On Wed, 30 Sept 2026 at 06:48, Pasquale Pagano ***@***.***> wrote: Independent Replication & Extension: Mesa 26.2.3, Desktop Environment, and 14B Scaling Thanks for this write-up! I was able to independently replicate your findings and test a few additional real-world scenarios on an Arc B580 (BMG G21, 12 GB) using the newer *Mesa 26.2.3* via the kisak-mesa PPA on Ubuntu 26.04. Here is the data confirming the performance jump, along with observations on shader compilation and 7B vs 14B scaling. ------------------------------ Hardware & Environment - *GPU:* Intel Arc B580 Founder Edition (12 GB VRAM, xe kernel driver) - *CPU:* Intel Core i5-14400F (no iGPU) - *OS:* Ubuntu 26.04 (Kernel 7.2.6-070206-generic) - *Desktop / Display:* GNOME / Wayland — *GPU drives the main display* (~700–900 MiB VRAM used by desktop compositor, unlike OP's headless setup) - *Stack:* Ollama (Vulkan / libggml-vulkan.so), Mesa 26.2.3-kisak ------------------------------ Replication of Original Models (eval rate / decode) Model Context Mesa 26.0.8 (OP) Mesa 26.1.7 (OP Headless) Mesa 26.2.3 (My Test, Display Attached) Status gemma4:latest (E4B, Q4_K_M) 4096 30.25 tok/s 66.99 tok/s *61.49 tok/s* (sustained: 59.82 tok/s) *Replicated (~2x gain)* qwen3:8b 4096 29.79 tok/s 61.01 tok/s *47.15 tok/s* (long 1770-token run) *Replicated (+58%)* *Note on Qwen3 throughput:* My run was evaluated across a sustained generation of 1774 tokens with GNOME compositor overhead, which explains the delta vs OP's 400-token headless test. ------------------------------ SPIR-V Shader Compilation Overhead (Cold vs Warm Cache) On gemma4, the first inference run exhibited a noticeable delay during prompt evaluation due to driver-level shader compilation: - *Cold cache (Run 1):* prompt eval: 5.44s (9.00 tok/s) - *Warm cache (Run 2):* prompt eval: 181.5 ms (269.93 tok/s) — *~30x faster TTFT* Anyone benchmarking ANV on Battlemage should ensure they run a warm-up prompt first to avoid mistaking shader compilation latency for compute regression. ------------------------------ Extending to Coding Models: qwen2.5-coder (7B vs 14B) I also tested coding workloads to check how memory bandwidth and compute scale on Battlemage up to the 12 GB VRAM limit. Both ran with 100% layer offload on GPU: Model Size Prompt Eval (Warm) Decode Throughput VRAM Status qwen2.5-coder:7b ~4.7 GB 301.04 tok/s *58.34 tok/s* ~5.3 GB total footprint qwen2.5-coder:14b ~9.0 GB 432.72 tok/s *31.65 tok/s* ~10.1 GB footprint (fits comfortably) Takeaways: 1. *Clean Bandwidth Scaling:* Moving from 7B to 14B cut the decode speed almost exactly in half (1.84x factor, 58.34 -> 31.65 tok/s), showing linear memory bandwidth saturation with no weird driver bottlenecks. 2. *14B is very usable:* 31.65 tok/s makes 14B coding models completely practical for daily interactive local development on an entry-level GPU under Linux. Mesa 26.1+ is definitely a hard requirement for anyone running local LLMs on Battlemage. — Reply to this email directly, view it on GitHub <#27777?email_source=notifications&email_token=AAWYQMGUALA5XC6XPL4B6ED5RTQIPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBWG43TKNZSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18677572>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWYQMAMGOYXO4EF3SUYTNT5RTQIPAVCNFSNUABIKJSXA33TNF2G64TZHM3DCMRTGU2DOOBUHNCGS43DOVZXG2LPNY5TCMBWHE2DKMBQUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>