Description
Currently we precompile the built-in shaders manually using xb buildshaders and push them to the repository.
I think eventually we should switch to building shaders in xb setup. The most important reason is that we aren't able to build shaders for all GPU APIs from all build host operating systems. FXC, the Direct3D Shader Model 5 shader compiler, while can be executed through Wine, doesn't have a native Linux version. DXC (the SM6 compiler) is open source and has a Linux version, but currently SM5 is the minimum target as some GPUs don't have SM6-supporting drivers (old Intel GPUs, UWP on the Xbox One). But another issue is the MSL compiler in the future — if I understand correctly, it's available only on macOS.
The other advantages of compiling the shaders during the build process are CI validation of the shader code, the lack of the possibility for the shader sources and the bytecode to become desynchronized, and no merge conflicts in pull requests modifying shaders in case they've been touched in other commits since the submission.
The reason why xb setup is preferred over the C++ build system integration is to avoid complications of setting up dependencies for all Premake targets and build systems themselves, including checking whether the shaders are still up to date.
For this, aside from the Windows SDK, we'll need the Vulkan SDK in %VULKAN_SDK% on AppVeyor. On Drone, just the Vulkan SDK will be needed. However, since the SPIR-V tool chain is open source, we can fall back to bootstrapping, similar to what we do for Premake now, if making sure the SDK is installed on the CI is difficult.
The shaders will need to be placed in a separate .gitignored directory like the build one currently with the subdirectory tree reflecting the source tree for directories containing shaders (I'm not yet sure if we should reuse build for this purpose as it's more of a sandbox for the actual build system, where it largely owns all the naming of the files).