[WIP] Vulkan stats - #789
Conversation
|
Seams like i targeted the wrong branch, and should target dev, sorry. |
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 -- JustVugg#891, JustVugg#729, JustVugg#789 -- all written
by people without the hardware, and reviewed by reading the diff. JustVugg#892 and
JustVugg#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 JustVugg#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: JustVugg#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 (JustVugg#879).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@Neppord status check on this WIP — no pushes since Aug 4. Still active? If the Vulkan telemetry direction is alive, note that #891 covers the residency-reporting half (currently red, needs a rebase) — worth coordinating so you don't collide. If it's parked, no shame in closing and reopening when it's ready; open WIPs cost review attention. |
|
Closing as dormant — no pushes in two weeks and no reply to the status check. The residency half is covered by #891 (which is currently red and needs a rescue, so that area is genuinely still open). You've been active elsewhere in the tracker, so please read this as "reopen when you resume" rather than a rejection — the stats surface is still wanted, and it'll be easier to re-cut against |
|
Yes, thank you. I have not had to look through the whole thing, which I want before it will be taken out of WIP. If I get around to doing that, I will ask it to be opened again. |
2 participants
Summary
This is a placeholder PR for implementing the same statistic features that exists for cuda, but for vulkan. More specificaly the vmem and the expert recidents when runing the web ui.
Validation
make -C c checkmake -C c cuda-test(if applicable)Compatibility