Skip to content

ci: build and run the Vulkan backend, under Lavapipe - #895

Merged
JustVugg merged 1 commit into
devfrom
ci/vulkan-lavapipe
Aug 9, 2026
Merged

ci: build and run the Vulkan backend, under Lavapipe#895
JustVugg merged 1 commit into
devfrom
ci/vulkan-lavapipe

Conversation

@JustVugg

@JustVugg JustVugg commented Aug 8, 2026

Copy link
Copy Markdown
Owner
grep -rn "VK=1\|glslc\|vulkan" .github/workflows/
(nothing)

The Vulkan backend has never been compiled by any job in this repository. Not built, not linked, not run. backend_vulkan.c and the four GLSL shaders could be broken on dev right now and every check would stay green.

Three Vulkan PRs are open as this lands — #891, #729, #789 — all written by people without the hardware and reviewed by reading the diff. #892 and #887 are Vulkan bug reports from users whose cards nobody here has.

What Lavapipe buys

Mesa's software Vulkan runs on any x86 runner. Locally:

[VK] VRAM pressure-proofing: memory_priority on, memory_budget on
[VK] ready: llvmpipe (LLVM 20.1.2, 256 bits), compute qfam 0, memtype 0,
     fused gate+up, absorb attention
[VK] expert tier active: routed quantized experts on the GPU (budget 320)

So it proves the .comp shaders compile to SPIR-V, the loader finds a device, queue-family and memory-type selection work, extension negotiation works, and the expert tier initialises.

What it does not

Nothing about performance. It is a CPU rasteriser and will be slower than the ordinary CPU path; any tok/s measured under it is meaningless.

No driver-specific behaviour. The VK_EXT_memory_budget under-reporting on RADV RX 6000 that @MasterCATZ documented in #891 will not appear here. Real cards still need @Limalski, @BranBushes, @MasterCATZ and @krusherpt.

This is a compile-and-execute gate, not a benchmark, and the job name says so.

The job

Two steps that fail independently:

  1. make colibri VK=1, plus assertions that all four .spv exist and the binary links libvulkan. glslc can reject a .comp while backend_vulkan.c compiles perfectly, so shader compilation is its own failure mode and gets its own check.
  2. Run against Lavapipe with a fabricated config.json — enough to reach coli_vk_init(), which runs before any weight is read. The run then fails on the missing model, which is expected and ignored; the [VK] banner is what is asserted.

Verified in both directions

Passing, with the exact commands the job runs:

27532 shaders/attention_absorb.spv     linked against libvulkan  OK
19120 shaders/qmatmul.spv              PASS: [VK] ready
16924 shaders/qmatmul_gate_up.spv      PASS: expert tier active
 4180 shaders/rmsnorm.spv

Negative control, one shader removed:

[VK] cannot open shaders/qmatmul.spv
[VK] Vulkan backend unavailable (tried shaders/qmatmul.spv; ...)
PASS: the gate FAILS, as it must

A job that cannot fail is worse than no job, and this repo shipped one of those a week ago: #868's release check was named "coli would not resolve these next to itself" and asserted file existence, so it passed while the launcher structurally could not select the engine — which is #879.

🤖 Generated with Claude Code

    grep -rn "VK=1\|glslc\|vulkan" .github/workflows/
    (nothing)

The Vulkan backend has never been compiled by any job in this repository.
Not built, not linked, not run. backend_vulkan.c and the four GLSL shaders
could be broken on dev right now and every check would stay green.

Three Vulkan PRs are open as this lands -- #891, #729, #789 -- all written
by people without the hardware, and reviewed by reading the diff. #892 and
#887 are Vulkan bug reports from users whose cards nobody here has.

WHAT LAVAPIPE BUYS, AND WHAT IT DOES NOT

Mesa's software Vulkan runs on any x86 runner. Locally it produces:

    [VK] VRAM pressure-proofing: memory_priority on, memory_budget on
    [VK] ready: llvmpipe (LLVM 20.1.2, 256 bits), compute qfam 0, memtype 0,
         fused gate+up, absorb attention
    [VK] expert tier active: routed quantized experts on the GPU (budget 320)

So it proves: the .comp shaders compile to SPIR-V, the loader finds a
device, queue-family and memory-type selection works, the extension
negotiation works, and the expert tier initialises.

It proves NOTHING about performance -- it is a CPU rasteriser and will be
slower than the ordinary CPU path, so any tok/s measured under it is
meaningless. It also does not reproduce driver-specific behaviour: the
VK_EXT_memory_budget under-reporting on RADV RX 6000 in #891 will not
appear here. Those still need @Limalski, @BranBushes, @MasterCATZ and
@krusherpt on real cards.

THE JOB

Two steps, both of which can fail independently:

1. `make colibri VK=1` plus an assertion that all four .spv exist and that
   the binary actually links libvulkan. glslc can reject a .comp while
   backend_vulkan.c compiles perfectly, so shader compilation is its own
   failure mode and gets its own check.

2. Run against Lavapipe with a fabricated config.json -- enough to reach
   coli_vk_init(), which runs before any weight is read. The run then fails
   on the missing model, which is expected and ignored; what is asserted is
   the [VK] banner.

VERIFIED IN BOTH DIRECTIONS

Passing, with the exact commands the job runs:

    27532 shaders/attention_absorb.spv    linkato a libvulkan OK
    19120 shaders/qmatmul.spv             PASS: [VK] ready
    16924 shaders/qmatmul_gate_up.spv     PASS: expert tier active
     4180 shaders/rmsnorm.spv

Negative control, one shader removed:

    [VK] cannot open shaders/qmatmul.spv
    [VK] Vulkan backend unavailable (tried shaders/qmatmul.spv; ...)
    PASS: the gate FAILS, as it must

A job that cannot fail is worse than no job, and this repo has shipped one
of those recently: #868's release check was named "coli would not resolve
these next to itself" and asserted file existence, so it passed while the
launcher could not select the engine (#879).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@JustVugg
JustVugg merged commit febdba8 into dev Aug 9, 2026
18 checks passed
@JustVugg
JustVugg deleted the ci/vulkan-lavapipe branch August 9, 2026 06:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant