Disable GL_KHR_cooperative_matrix Vulkan extension if not available.

[mbaudier]

Allows to support Vulkan on platforms where the GL_KHR_cooperative_matrix extension is not available, such as Debian 12/bookworm.

Resolves #11052.

[0cc4m]

I tested it and it's fine on systems with versions new enough to support the extension.

The code looks good, I only have two minor comments. Once those are addressed I'll merge it. Thank you for the contribution!

[jeffbolznv]

LGTM. Yet another reason we should consider building glslc from a known good commit.

[LostRuins]

Hi, I'm having some issues after this PR, not sure if it's a user error on my part.

Scenario: My glslc and vulkan install supports coopmat1. However, I wish to produce a build that excludes coopmat as if I did not have it.

Approach: I am manually setting GGML_VULKAN_COOPMAT_GLSLC_SUPPORT to not defined, meanwhile VK_KHR_cooperative_matrix remains set to 1 from the headers in the latest installed Vulkan SDK.

Result: Builds fine. However at runtime during ggml_vulkan: Compiling shaders I get a segmentation fault. Running a backtrace shows it happens at

0x00007ffe88eb361b in vk_gr2608GetInstanceProcAddr () from C:\Windows\System32\DriverStore\FileRepository\nvmii.inf_amd64_881a68749106a57c\nvoglv64.dll

Now if I define GGML_VULKAN_COOPMAT_GLSLC_SUPPORT, then everything continues to work as per normal, but it is my understanding that I should be able to toggle this flag rather than be forced to use it with the latest Vulkan SDK on windows?

To reproduce this: Have a system that supports coopmat, install the latest Vulkan SDK on windows, then remove this line

llama.cpp/ggml/src/ggml-vulkan/CMakeLists.txt

Line 22 in 8d59d91

add_compile_definitions(GGML_VULKAN_COOPMAT_GLSLC_SUPPORT)

[0cc4m]

Now if I define GGML_VULKAN_COOPMAT_GLSLC_SUPPORT, then everything continues to work as per normal, but it is my understanding that I should be able to toggle this flag rather than be forced to use it with the latest Vulkan SDK on windows?

No, the goal is just to ensure compatibility with Debian (or other Linux distros) where the package manager versions of glslc and the Vulkan headers are too old to support the VK_KHR_cooperative_matrix extension. On systems without a package manager (like Windows) you can (and should) just install the latest SDK.

I see wrong results when I force disable GGML_VULKAN_COOPMAT_GLSLC_SUPPORT, but no crash. This could be fixed, but it's not a case that is likely to happen on any system, since it requires a mismatch between what glslc supports and what the Vulkan headers support.

[mbaudier]

To put it slightly differently, GGML_VULKAN_COOPMAT_GLSLC_SUPPORT is not meant to be set manually like the usual GGML_* flags, but to be automatically set when an older Vulkan SDK is detected. It is actually an internal flag, maybe it should be clearer in its name?

[LostRuins]

update: checked with occam and this worked for me

diff --git a/ggml/src/ggml-vulkan/ggml-vulkan.cpp b/ggml/src/ggml-vulkan/ggml-vulkan.cpp
index 07745242..bc6ff4a3 100644
--- a/ggml/src/ggml-vulkan/ggml-vulkan.cpp
+++ b/ggml/src/ggml-vulkan/ggml-vulkan.cpp
@@ -2184,6 +2184,10 @@ static vk_device ggml_vk_get_device(size_t idx) {
             device->coopmat_support = false;
         }

+#if !defined(GGML_VULKAN_COOPMAT_GLSLC_SUPPORT)
+        device->coopmat_support = false;
+#endif
+
         std::vector<vk::QueueFamilyProperties> queue_family_props = device->physical_device.getQueueFamilyProperties();

         // Try to find a non-graphics compute queue and transfer-focused queues

allows me to build as if i don't have coopmat, no crash and output seems coherent, at non-coopmat speeds, output binary is 30% smaller.

But he did mention its not a supported use case, instead I should use GGML_VK_DISABLE_COOPMAT to disable at runtime.