spirv-builder 0.10 not on crates.io

[ArrEssJay]

Expected Behaviour

Latest published spirv-builder crate on crates.io is 0.9 - this requires toolchain nightly-2023-05-27, which is inconsistent with nightly-2024-04-24 currently referred to in rust-gpu top level rust-toolchain.toml.

This appears to be resolved in spirv-builder 0.10, however this is not published.

[LegNeato]

Ah, we should push a new version every time we bump on master as folks may be using builder directly via cargo. Until it is published you can use a git dependency. Let me know if for some reason that doesn't work.

[utensil]

Sorry to barge in. I have a related question:

From the wgpu runner examples of rust-gpu, and from how GraphiteEditor handle it, one can see that the building of rust shader crates into SPIRV is done via a standalone CLI program (GraphiteEditor made a lightweight wrapper around it to call the CLI from Rust to compile shader crates).

Is this the encouraged practice? I was imagining a more rust native way to integrate the host program (handles non-GPU logic, and GPU runtime and the execution of shaders) and the compilation of shader crates.

Particularly, if the host rust program need to use a newer rust nightly toolchain (maybe required by other crates in the host program) than spirv-builder (which needs significant more work to bump rust toolchain, thus moving slower), this way seems to be the only option? GraphiteEditor seems to choose to use the same rust toolchain for the host program as spirv-builder.

[LegNeato]

Yes, some projects use the required pinned nightly via spirv-builder, generate the .spv file, and then consume that via their host rust program using stable / whatever rust version they need for their application. Another example is https://github.com/charles-r-earp/krnl I believe. We support this and want to add documentation and examples to make it easier to discover.

The project's goal is to track nightly so at least if folks are using nightly they can use one toolchain, and then create a tool (cargo gpu) to handle all the manual gyrations for other modes and reduce toil in general for folks who don't need to control the build system themselves.

Long-term we want to be in rustc 😄

[schell]

@utensil I also do this in renderling/shaders. I prefer this setup because it makes recompilation explicit and indeed, you can keep using latest stable or nightly for the rest of your project. It also enables other workflows, like using naga to translate the generated SPIR-V into WGSL for web.

[utensil]

Thank you both for the explanations and pointers to examples ❤️

I had starred both repos before but didn't realize that they are both based on rust-gpu 😮