llama.mak: support building Vulkan backend

[Peter0x44]

Requires the Vulkan SDK installed to build.
It can be downloaded from: https://vulkan.lunarg.com/

[Peter0x44]

A good talk on what to expect regarding Vulkan in llama.cpp:

https://fosdem.org/2026/schedule/event/CZSPSC-llama-cpp-vulkan/

I don't love depending on the Vulkan SDK, and nothing it does is really irreplaceable, but upstream expects it, so it's what I used.

[Peter0x44]

to give a bit more overview of what vulkan sdk provides, just in case something is unclear.

glslc - compiler for glsl -> spir-v. Vulkan does not support text shaders, it instead consumes spir-v IR at runtime.
vulkan headers - self explanatory. In my own projects, I prefer volk, which is unofficial.
volk is more-or-less a vulkan equivalent of GLAD. It calls LoadLibrary on vulkan-1.dll which ships as part of Windows, at C:\Windows\System32.
(not that it's used here).

vulkan library - vulkan-1.lib import lib for vulkan-1.dll

Though I have not tried to, these components could all be built and provided separately, in theory (and likely practice).

Here are the official vulkan build instructions, for reference.
https://github.com/ggml-org/llama.cpp/blob/master/docs/build.md#for-windows-users

[skeeto]

Thanks, @Peter0x44. I gave it a test drive and all seems to be in order, including a performance boost on my system when leveraging Vulkan. I'm happy to merge after sorting out a few details:

1. Perhaps instead of USE_VULKAN it's activated merely by providing a Vulkan installation, e.g. defining VULKAN_SDK. I tested with an older Vulkan SDK I already had on hand, 1.3.280.0. Hard-coding a version like 1.4.328.1 will require maintenance, and users will likely need to provide this anyway. Your hard-coded path would be fine as an example make invocation.

2. Instead of {def,inc,ldflags}_vk should it += to the appropriate variables? It does so with dll. This would require re-ordering a few things.

3. A common subtly in meta-programming builds: Should the shader generator be built with the "cross" compiler? You're already on track to treat it as a different toolchain by not using CPPFLAGS. When metaprogramming in a cross-build, there will be two toolchains in play, and it's easy to mix them up. Though it's kind of a moot point here because there's probably no cross Vulkan SDK anyway, so this part isn't cross-build compatible anyway.

4. This is my fault for not enforcing consistency in the past, but my mental model is: ALL_CAPS for variables the user might be interested in overriding (possibly by the environment with make -e) and snake_case for "internal" variables not to be touched by users. CROSS, CPPFLAGS, and VULKAN_SDK are examples of the former, while def, inc, dll, exe are examples of the latter. GGML_VERSION_MAJOR and such breaks this rule, and I should probably fix it (in a followup to this PR). In your changes some as certainly the latter category, but maybe a couple should be in the former? (Should overriding the shader build directory be a UI knob?)

To check my understanding, I actively made these changes in 770df03.

[Peter0x44]

Perhaps instead of USE_VULKAN it's activated merely by providing a Vulkan installation, e.g. defining VULKAN_SDK. I tested with an older Vulkan SDK I already had on hand, 1.3.280.0. Hard-coding a version like 1.4.328.1 will require maintenance, and users will likely need to provide this anyway. Your hard-coded path would be fine as an example make invocation.

that's sensible, I was just thinking if anyone wanted to build/supply the components of the vulkan SDK independently.
Fine with me.

Instead of {def,inc,ldflags}_vk should it += to the appropriate variables? It does so with dll. This would require re-ordering a few things.

Yeah, it can do that. It's sensible

A common subtly in meta-programming builds: Should the shader generator be built with the "cross" compiler? You're already on track to treat it as a different toolchain by not using CPPFLAGS. When metaprogramming in a cross-build, there will be two toolchains in play, and it's easy to mix them up. Though it's kind of a moot point here because there's probably no cross Vulkan SDK anyway, so this part isn't cross-build compatible anyway.

You are right about this. It should be built with the host compiler.

But, those people will have to still override glslc to point to the native one, too, I think.

This is my fault for not enforcing consistency in the past, but my mental model is: ALL_CAPS for variables the user might be interested in overriding (possibly by the environment with make -e) and snake_case for "internal" variables not to be touched by users. CROSS, CPPFLAGS, and VULKAN_SDK are examples of the former, while def, inc, dll, exe are examples of the latter. GGML_VERSION_MAJOR and such breaks this rule, and I should probably fix it (in a followup to this PR). In your changes some as certainly the latter category, but maybe a couple should be in the former? (Should overriding the shader build directory be a UI knob?)

I think GLSLC should also be one of the former. I can't think of a good reason to override the shader build directory, so probably it should be lowercase.

[Peter0x44]

Another thing I was going to send a follow up patch for, is openmp. So if we switch this from a USE_VULKAN, what would be a sensible pattern for a USE_OPENMP?
Not a big deal, just a minor point on consistency.