Document Shader compilation in the framework

[tomadamatkinson]

There are lots of different ways of handling shaders for an application. We should aim to discuss the pros and cons of each way and also Vulkan Samples setup

Acceptance Criteria:

• Create a README that discusses the following
• Manual shader compilation
• Automating shader compilation with a build system
• Pros and cons of bundling shaders within an application or loading shader code at runtime
• Offline shader compilation in Vulkan Samples

[JoseEmilio-ARM]

We have a private fork of Vulkan Samples that can do GLSL shader hot-reloading, and this has been really useful during development as it allowed us to tweak and debug shaders without having to re-build the application. This feature is perhaps most useful and relevant during the development of a new sample, but could also help for learning from existing samples to tweak parameters that are not exposed by the UI.

Would it be possible to leave on-line compilation as an opt-in build option? We are happy to share our existing hot-reloading solution in that case.

Alternatively, the new system could be designed in a way that it can accept hot-reloading of SPIRV shaders. That way we could use the new tools to compile shaders (GLSL or HLSL) while the application is running, and get a similar functionality without the need of online compilation?

[tomadamatkinson]

We should be able to achieve hot reloading with either offline or online shaders. The only difference is what recompiles the shaders.

An online approach is likely better as you can automate as many steps as possible.

Are you able to share your hot-reloading work against the current main or would it require more work to port it from your fork to main?

[JoseEmilio-ARM]

Agree, I'm happy to proceed to remove the current online compilation, and focus on offline compilation for maintainability, then add reloading at a later stage.

It would take some effort to port our solution, but we could also share the plain files for reference. The main difference would be that the user will likely need to run a different process in parallel in charge of detecting HLSL/GLSL changes and compiling the shaders, and then the samples need to detect changes in SPIRV and re-build the pipelines.

[SaschaWillems]

I think we can close this once GLSL shader compilation works similar to the HLSL side of things, where shader compilation is done as part of the build process.

[SaschaWillems]

Closing this to clean up issues related to finalizing HLSL support.