cmake: simplify vulkan shader test logic

[bandoti]

This PR adds a CMake function to simplify the shader feature-detection logic. In addition, the requisite preprocessor defines are shared with the vulkan-shaders-gen project through an auto-generated cmake file, preventing the need to pass them along manually.

[bandoti]

@jeffbolznv I think you were right about using the external project add for vulkan-shaders-gen for both the cross-compile and the regular build. I am going to try that here now I guess the timing is right. 😊

[jeffbolznv]

Thanks for making these cleanups. The changes look reasonable to me, though I don't know if there are any weird consequences of passing cmake arguments via file.

[bandoti]

No problem. We'll see how the CI responds. I added a couple cross-compile builds there so at very least we have the basic compile-checks covered.

[0cc4m]

Interesting. This doesn't seem much simpler, though. It's about as much code and going through an external file is slightly convoluted. But I don't know enough about cmake to judge that particularly well, so I'll leave it up to you to decide what is better.

[bandoti]

The primary motivation is to only change one place when new extension checks are added.

Because the Vulkan-shaders-gen project had several bugs associated with missing defines, this change would ensure that they will be present without having to duplicate flags within the sub project.

Also, the "subdirs" loading is replaced by unifying the cross-compile approach with a regular build, both using ExternalProject_Add now.

[bandoti]

The one issue with using the file copy, however, is that one cannot build the Vulkan-shaders-gen without building ggml-vulkan, and so it becomes an implementation detail despite being an external project.

I am happy to undo that change if this is not desirable. From my point of view this is the only way I've built the app, but perhaps there's a reason to decouple them.

The net effect is just that we need to update 3 spots instead of 1 when adding new extension capabilities.

[bandoti]

I went ahead and removed the auto-generated file, but as a compromise the set of extension arguments are appended to a list which gets expanded automatically when adding vulkan-shaders-gen project.

So, when adding new extension checks we just need to make two changes:

1. In ggml/src/ggml-vulkan/CMakeLists.txt:

    test_shader_extension_support(
        "GL_KHR_cooperative_matrix"
        "${CMAKE_CURRENT_SOURCE_DIR}/vulkan-shaders/test_coopmat_support.comp"
        "GGML_VULKAN_COOPMAT_GLSLC_SUPPORT"
    )

2. And ggml/src/ggml-vulkan/vulkan-shaders/CMakeLists.txt:

if (GGML_VULKAN_COOPMAT_GLSLC_SUPPORT)
    add_compile_definitions(GGML_VULKAN_COOPMAT_GLSLC_SUPPORT)
    message(STATUS "Enabling coopmat glslc support")
endif()

Well, and of course the shader test itself... 😅

[0cc4m]

I think either is fine, you know a lot more than me about cmake. As long as it works and I can figure out where new extensions have to go, I'm happy. 😄

[bandoti]

@0cc4m glad I could be of help. Learning Vulkan is on my bucket list but I'm not there yet—maybe some day I'll be able to help you all with the actual work! 😊