Add cargo tool

[XAMPPRocky]

Proposal

We've been working a lot on build system improvements (#239) and improving the example runners (E.g. #259), but right now there isn't a complete workflow for people working on a shader. There is SHADERed which does provide a nice IDE, but a lot of developers (myself included) don't use an IDE and I'd like to have a command that I could run and test my shader without writing or copying a whole bunch of boilerplate.

To that end, I would propose creating a new tool (cargo-gpu) that merges the some of the functionality of spirv-builder with the examples/runners to provide a complete build, test, and run workflow for writing Rust shaders.

Proposed Commands

• cargo gpu run
  • Builds and renders the shader on your GPU.
• cargo gpu watch
  • Adds hot reloading for builds.

Proposed arguments

• -R/--renderer=[wgpu,vulkan] The renderer backend to use.

[khyperia]

Is this for us in particular working on rust-gpu, or everyone else?

If everyone else, then we can't include runners, because the runners assume particular bindings and configurations and whatnot (can't generically run any shader), and then if it can't be automatically tested/executed, I'm not sure how this is different than a typical cargo build. We could create something like shadertoy, but that seems like a very different use case and design goals.

If it's for just us, is there an advantage to making it an installed binary over having plain scripts or a helper cargo run builder -- stuff?

[XAMPPRocky]

We could create something like shadertoy, but that seems like a very different use case and design goals.

I don't think the goal would be to run any shader, at least not without the writers of the shaders using some conventions and configuration. It's to provide a good enough scratchpad for prototyping and testing. If we want to have an ecosystem of shader crates, people need to be able to build and test the SPIR-V target in their crate with a minimal amount of boilerplate, preferably none. Especially for crates that are already supporting multiple targets, they're going to be less willing to include a whole runner just for our target.

There are ways we can simplify the implementation with conventions. For example; Since we allow multiple entry points we can have a naming scheme for cargo-gpu's entrypoints so for when you're testing and working on it you can use those, and then you can have separate entry points for use in production. Similar to how in SwiftUI you can have a preview version of your component.

// Normal entrypoint
#[spirv(vertex)]
pub fn vs() {
   // ...
}

// Cargo GPU entrypoint
// `cargo gpu run` implies `--cfg cargo_gpu`
#[cfg(cargo_gpu)]
#[spirv(vertex)]
pub fn __cargo_gpu_vs() {
  // ...
}