Use cmake rules to re-compile SPIR-V when shaders change

[jherico]

Being able to experiment with the shader source code and see the resulting changes in the would be really useful for the examples.

I've modified my branch to do this, mostly relying on this macro.

[SaschaWillems]

Sorry for the late reply. I thought about this several times (and also had prebuild events for this at some point), but I'm not 100% sure on this yet. Mostly because I've recently stumbled upon a problem with shaders generated with a recent glslangvalidator failing on a certain ISV. But it's on my list :wink:

[Delwin9999]

Just an FYI: I can't make pull requests but this is what I use.

set(KERNELS ${CMAKE_SOURCE_DIR}/test/vulkanTests/shaders/display_mesh/mesh.vert ${CMAKE_SOURCE_DIR}/test/vulkanTests/shaders/display_mesh/mesh.frag )

set(COMPILED_KERNELS ${CMAKE_SOURCE_DIR}/test/vulkanTests/shaders/display_mesh/mesh.vert.spv ${CMAKE_SOURCE_DIR}/test/vulkanTests/shaders/display_mesh/mesh.frag.spv )

add_executable(vulkan_test_mesh ${SOURCES} ${HEADERS} ${EXTERNAL_HEADERS} ${KERNELS} ${COMPILED_KERNELS} ${EXTERNAL_ASSETS})

foreach(KERNEL ${KERNELS}) add_custom_command(OUTPUT ${KERNEL}.spv COMMAND ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/glslc ${KERNEL} -g -o ${KERNEL}.spv DEPENDS ${KERNEL} COMMENT "Rebuilding ${KERNEL}.spv" ) message(STATUS "Generating build commands for ${KERNEL}.spv") endforeach()

[DanOlivier]

This is exactly what I did now, having recently started to work on this again.

It is also what I did last time, in addition to converting the samples to use Vulcan-Hpp, and rationalizing the integration of 3rd-party source code (each platform is different, but I want to control this especially).

I improved on what I did last time, and now, a typical leaf CMakeLists.txt would look like this:

buildExample(textoverlay
    textoverlay.cpp
SHADERS
    shaders/background.frag
    shaders/background.vert
    shaders/mesh.frag
    shaders/mesh.vert
    shaders/text.frag
    shaders/text.vert
ASSETS
    models/cube.dae
    textures/skysphere_bc3_unorm.ktx
    textures/skysphere_astc_8x8_unorm.ktx
    textures/skysphere_etc2_unorm.ktx
    textures/round_window_astc_8x8_unorm.ktx
    textures/round_window_etc2_unorm.ktx
    textures/round_window_bc3_unorm.ktx
)

At first, the ASSETS were being copied, but I changed that to use softlinks, so as not to waste space. Each shader (tagged with SHADERS) is co-located with the example program, and possibly duplicated from one program to another. This would be embarrassing, if I didn't see a better solution available: the way they do it here:

add_shader_library(shader_library
  SOURCES
    double_numbers.comp
    hardcode_pos_triangle.frag
    hardcode_pos_triangle.vert
    simple_fragment.frag
    simple_vertex.vert
    test.vert
    foo/test.frag
    foo/test.glsl
    models/model_setup.glsl
)

Then, a downstream program can do this:

add_shader_library(fill_buffer_shaders
  SOURCES
    fill.frag
    fill.vert
  SHADER_DEPS
    shader_library
)

add_vulkan_sample_application(fill_buffer
  SOURCES main.cpp
  LIBS
    vulkan_helpers
  MODELS
    standard_models
  SHADERS
    fill_buffer_shaders
)

A library is built, packing only compiled shader programs (or other resources), and example programs just link to them (the resources are available as symbols at runtime, and these resource libraries can be dynamically loaded).

I haven't tried to build from your tree, jherico, I only scanned it quickly, but I will soon.