Skip to content
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

Closed

Conversation

tomadamatkinson
Copy link
Collaborator

@tomadamatkinson tomadamatkinson commented Feb 27, 2024

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:

  • constant_data
  • msaa

Fixes #

General Checklist:

Please ensure the following points are checked:

  • My code follows the coding style
  • I have reviewed file licenses
  • I have commented any added functions (in line with Doxygen)
  • I have commented any code that could be hard to understand
  • My changes do not add any new compiler warnings
  • My changes do not add any new validation layer errors or warnings
  • I have used existing framework/helper functions where possible
  • My changes do not add any regressions
  • I have tested every sample to ensure everything runs correctly
  • This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

  • I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

  • I have tested the sample on at least one compliant Vulkan implementation
  • If the sample is vendor-specific, I have tagged it appropriately
  • I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
  • Any dependent assets have been merged and published in downstream modules
  • For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
  • For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
  • For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

Comment on lines 30 to 38
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()
Copy link
Contributor

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?

Copy link
Collaborator Author

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?

Copy link
Contributor

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.

Copy link
Collaborator Author

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

Copy link
Contributor

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?

Copy link
Collaborator Author

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

@tomadamatkinson tomadamatkinson changed the title WIP: Offline Shaders (Without Variants WIP: Offline Shaders (Without Variants) Feb 27, 2024
@@ -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);
Copy link
Contributor

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?

Copy link
Collaborator Author

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

@jherico
Copy link
Contributor

jherico commented Feb 28, 2024

I put all my suggestions into tomadamatkinson#3

@tomadamatkinson
Copy link
Collaborator Author

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!

@jherico
Copy link
Contributor

jherico commented Mar 1, 2024

@tomadamatkinson Sure. Let me know anything you need.

@SaschaWillems
Copy link
Collaborator

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.

@jherico
Copy link
Contributor

jherico commented Mar 1, 2024

@SaschaWillems Does that imply are you adding the SHADER_FILES_HLSL parameter to the CMake macros? Even if they don't get precompiled in your branch right now, having the CMake code be able to differentiate between HLSL and GLSL will save the work of a lot of tiny changes in this eventual PR.

@SaschaWillems
Copy link
Collaborator

SaschaWillems commented Mar 1, 2024

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...

@tomadamatkinson
Copy link
Collaborator Author

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?

@SaschaWillems
Copy link
Collaborator

SaschaWillems commented Mar 1, 2024

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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants