-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Offline Shaders (Without Variants) #950
WIP: Offline Shaders (Without Variants) #950
Conversation
bldsys/cmake/shader_helper.cmake
Outdated
find_program(SPV_VALIDATOR_EXECUTABLE spirv-val HINTS $ENV{VULKAN_SDK}/bin) | ||
if(NOT SPV_VALIDATOR_EXECUTABLE) | ||
message(WARNING "spirv-val not found! SPIR-V validation will not be performed. Please set VULKAN_SDK to the Vulkan SDK path.") | ||
endif() | ||
|
||
find_program(GLSLC_EXECUTABLE glslc HINTS $ENV{VULKAN_SDK}/bin) | ||
if(NOT GLSLC_EXECUTABLE) | ||
message(FATAL_ERROR "glslc not found! Shaders with .glsl extension will not be compiled to SPIR-V. Please set VULKAN_SDK to the Vulkan SDK path.") | ||
endif() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, this won't work that well for us, we don't generally have the Vulkan-SDK on our build servers.
Could we not just add glslangValidator and spirv-tools as submodules and build these as required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we bundle the SPIRV with the repository instead of ignoring it then there wouldn't be a need to install any tools out of the box? Tools would only be needed if you change the shaders
Is there any capability for you to install tools on your build servers before running a build task? Possibly with a script?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we bundle the SPIRV with the repository instead of ignoring it then there wouldn't be a need to install any tools out of the box?
If they're bundled that's fine.
Is there any capability for you to install tools on your build servers before running a build task?
Anything is possible, I'm just looking for the path of least resistance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bundling is likely best here. Only maintainers of the shaders would require the tools needed to compile the shaders
There are only a few shaders which have variants (<5) I'm hoping to be able to simplify them further to remove the need entirely. That would mean that we would only have a single SPIRV per shader
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait, does that imply that building SPIR-V at build time when Sanders change locally is no longer a feature of this design? Right now if someone changes a shader and reruns an app they see the results of the change. Losing that seems like it would be a big deal.
Or is the idea that the bundled code only gets used as a fallback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just means that if you do want to alter the shaders you should at least have the tools installed to offline compile shaders. Most users should have this already with the Vulkan SDK
From the discussions in the working group the rough requirements are:
- Include HLSL alternatives for all shaders in the long run
- Do not include DXC or shader compilers within the project as these are assumed to be installed locally
- Prefer offline compilation over online compilation due to the point above
- Keep things simple with a single compile pass and document this for users
Previous attempts at solving this have been deemed too complex, hence this approach is all about being simple and removing complexity / unneeded shader usage.
Just updated the todo, I have a few samples left to simplify. Most samples work out of the box with this simpler model
Current bench mark for recompiling all shaders
cmake --build build --target vkb__shaders --parallel 0.98s user 0.91s system 456% cpu 0.416 total
@@ -31,6 +31,8 @@ | |||
#define __FILENAME__ (static_cast<const char *>(__FILE__) + ROOT_PATH_SIZE) | |||
|
|||
#define LOGI(...) spdlog::info(__VA_ARGS__); | |||
#define LOGW(...) spdlog::warn(__VA_ARGS__); | |||
#define LOGW(...) void(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you mean to leave this in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now yes, helps clean the logs up whilst testing shader changes. This will be reverted when the PR is out of WIP
Will leave this comment unresolved as a reminder
I put all my suggestions into tomadamatkinson#3 |
Thanks @jherico, if you are open to co-authoring I can create a list of todos and we can split up the remaining work on this PR. As stated on your created PR I'm happy to merge this after I've given it a spin, it looks to have cleaned up some of the more messy cmake! |
@tomadamatkinson Sure. Let me know anything you need. |
A quick note that I started adding HLSL shaders for some of the samples. We decided to do that first before adding a way to compile those in an automated way. Just wanted to let you know and it would be great if we could defer this until HLSL shaders are in. |
@SaschaWillems Does that imply are you adding the |
Right now it mostly means I have started evaluating how to get them in. I just started on that branch like a few minutes ago, so anything in it is very much non-final. But we decided to do it similar to how HLSL support was added to my samples. There will also be a way to compile the shaders in that branch. But it's very very early... |
I'm confused. This branch already supports HLSL shaders. The difficulty with previous approaches was supporting variants. Which we decided not to go forward with. This branch also removes variants from shaders with only a handful of samples left to patch. Are you stating that you are also not happy with the approach of this revised branch which follows the guidance given in the working group? If so which parts of this branch are not solved how you imagined they would be solved? |
I started adding actual HLSL shaders the way we decided during our calls. I'm NOT going to add offline shader compilation. So imo your PR is still valid and what I'm doing now won't have much effect on your PR aside from maybe some minor things. Your PR is in mind the second step after we added actual shaders and need an easy way to compile them for other maintainers. Afair we wanted to first add in HLSL shaders and a way of loading SPIR-V generated from them (which is now possible thanks to Mobica's PR) and then add offline compilation for GLSL and HLSL at a later point. That also matches the proprosal for getting HLSL support into our samples I did some time ago. But a general plea: Can we lower the pace a bit. Right now things are moving so fast, and even just starting to make some code public starts of discussions. I'm doing all of this in my spare time after a hard work week and tbh. it really stresses me out not being able to work on anything without having to discuss it or trying to clear up confusion :( |
…rebuild on demand
21fda7d
to
b03c184
Compare
Description
As discussed on the 27/02/2024 working group call. The current offline shader approaches are overly complex due to the need to support for variants. Removing variants and simplifying the performance samples use of shaders may reduce the complexity of our shader compilation system.
This PR achieves offline compilation through a CMake helper. It also runs spirv-val to validate the spirv after it is created. For now the
.spv
files are not added to the repository, this may change if we agree on where they should be stored (build dir or next to source).The PR enables offline shaders for existing ApiVulkanSamples by altering
load_shader
After a configure and build the following commands have been tested on desktop
<path/to>/vulkan_samples batch -C api
<path/to>/vulkan_samples batch -C extensions
<path/to>/vulkan_samples batch -C general
<path/to>/vulkan_samples batch -C tooling
Performance samples work by attempting to find a precompiled shader before loading the source in ShaderSource. Variants have been removed by reworking shaders in samples
<path/to>/vulkan_samples batch -C performance
Todo:
Fixes #
General Checklist:
Please ensure the following points are checked:
Note: The Samples CI runs a number of checks including:
Sample Checklist
If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist: