More the build.rs scripts into the shaders #181
Conversation
| @@ -71,6 +71,10 @@ impl SpirvBuilder { | |||
| /// you usually don't have to inspect the path, as the environment variable will already be | |||
| /// set. | |||
| pub fn build(self) -> Result<PathBuf, SpirvBuilderError> { | |||
| if std::env::var("TARGETING_SPIRV").is_ok() { | |||
There was a problem hiding this comment.
Needed to stop the build script from being called recursively.
| use-installed-tools = ["spirv-builder/use-installed-tools"] | ||
| use-compiled-tools = ["spirv-builder/use-compiled-tools"] | ||
| use-installed-tools = ["example-shader/use-installed-tools"] | ||
| use-compiled-tools = ["example-shader/use-compiled-tools"] |
There was a problem hiding this comment.
I'm not really a fan of having to propagate these features, but I don't see a different way at the moment.
XAMPPRocky
added
the
s: waiting on review
|
Thanks so much for the PR! However, I think we still have too many unresolved questions with the build system and what direction we want to move in before we're able to accept this PR. Hopefully we can figure things out soon, but it's going to be a long exploratory process with a lot of prototypes, discussion, and debate before we decide where we want to go. |
|
Linking #48 which is our bigger tracking issue to try and figure out the overall path forward. It may be that we go with this specific approach, but there are some challenges also and considerations to support both for initial embedded GPU binaries in single pass, CPU shader evaluation and hotswapping/local fast iteration of shader crates, which makes all of this quite tricky with the constraints of Cargo |
As discussed on discord, this allows us to simply add the shader crate as a dependency and pull the compiled shader out of a
const.