Overlap with my `rust-gpu-cli` project?

[tombh]

For the last couple of Rust GPU projects I've been building my shaders using a standalone compiler, https://github.com/tombh/rust-gpu-cli, which is based on Bevy's https://github.com/Bevy-Rust-GPU/rust-gpu-builder.

My own reason for this is that I found it hard maintaining both my own application code and the shader code in the same repo. I think mostly because of rust-gpu's requirement for a specific rust-toolchain.toml.

I suspect cargo gpu will also solve this problem? In which case I'd like to contribute and focus my efforts here instead 🤓

So some reflections as both a rust-gpu and rust-gpu CLI frontend user:

• Should rust-gpu always support both ways of compiling shaders? Therefore auto-magically in a monorepo and with a standalone CLI frontend? Personally I'm currently leaning towards only supporting the latter. There are so many unconventional moving parts in compiling Rust shaders that I think hiding too much of the magic can lead to more harm than good.
• I see that cargo gpu will be published to crates.io. I wonder if it can be taken one step further and pre-compiled to static, cross-platform binaries? Possibly that's what you were discussing in https://github.com/Rust-GPU/cargo-gpu/issues/2? I've actually already had success with this on Github Actions: see https://github.com/tombh/rust-gpu-cli/pull/1/files It compiles librustc_codegen_spirv.{so,dylib,dll}. And then the actual final rust-gpu-cli app dynamically sets the LD_LIBRARY_PATH (or DYLD_FALLBACK_LIBRARY_PATH etc depending on the OS). The only problem I faced was that rustup can't cross-compile rustc-dev so I haven't been able to get aarch64 binaries for Linux compiling yet.
• Related to the previous point: is rust-toolchain.toml needed for compiling librustc_codegen_spirv.so or for compiling shaders or for both? Because if it's just for compiling librustc_codegen_spirv.so then does that mean that pre-compiled versions of librustc_codegen_spirv.so would avoid the need for cargo gpu to install its own rustup toolchains?
• Also related to the above, am I understanding correctly that this project installs (or plans to install) Rust toolchains under the hood? I think it'd be good to mention that in the README. Especially if it installs to ~/.rustup/toolchains. Also I think it'd be good to have the CLI be verbose by default about what it's doing. Even the simple fact that cargo gpu build is itself calling cargo build/rustc shouldn't be assumed knowledge. It took me a long time to arrive at even the basic understanding I currently have about how rust-gpu works. So as much as a turnkey solution is a great idea, in my experience hiding all the inner workings wasn't so useful.
• It's great to have bagged the cargo gpu namespace, but my first thought was that the gpu namespace could refer to a lot more than just compiling shaders. I wonder if something like cargo rust-gpu (whilst redundantly mentioning "rust") might be more appropriate?

[tombh]

Oh and some more ideas...

• Running as a daemon using rust-gpu's builder.watch()? I got that working in my project: https://github.com/tombh/rust-gpu-cli/blob/main/src/builder.rs#L186
• Adding all the SpirvBuilder::new() builder pattern arguments as CLI arguments? See: https://github.com/tombh/rust-gpu-cli/blob/main/src/builder.rs#L138

[tombh]

• And how could I forget, @schell's very own optional naga validation code: https://github.com/tombh/rust-gpu-cli/blob/main/src/validate.rs

[LegNeato]

Awesome, I hadn't seen your project (but now I see I have it starred so I must have at some point). We should definitely join forces 🚀

FWIW my plan for cargo gpu (and really even the rust-gpu GitHub org) is more than just the rust-gpu project. In fact, I've argued we should change the project name in order to make the distinction a lot clearer (and keep rust-gpu as the umbrella org / big tent). For example, if/when rust-cuda is rebooted it should natively slot into cargo gpu as well

[LegNeato]

(as an aside I've been trying to get a hold of @shfty for a while with no luck)

[schell]

Should rust-gpu always support both ways of compiling shaders?

I think this will always be the case. Likely because wrangling the cargo invocation to build shaders with the rustc_codegen_spirv backend is so unwieldy, it makes a lot of sense to wrap it with a library. That library is spirv-builder, and I think you'll always be able to depend on that in your project, if you like. There's been a little bit of discussion about cutting it up into pieces - but I imagine you could always have your project depend on whatever library those pieces end up in.

I tend to prefer the latter case you mentioned, where a standalone cli program compiles the shaders. This is mostly because I don't want to pin my project to an older nightly and also because the compile times can be a bit long.

[schell]

I see that cargo gpu will be published to crates.io. I wonder if it can be taken one step further and pre-compiled to static, cross-platform binaries?

We have been talking a bit about that. I'm for it, but it's a lot more effort than I have at the moment.

It's a good idea - I see that building rustc_codegen_spirv from scratch on my machine (an M1 Macbook Pro) takes ~1.5 minutes. That's not all that long, but it's definitely not "snappy".

I do feel that it's a nice-to-have but compiling locally is the 20/80 IMO. (The 20% effort that gets you 80% value).

[schell]

Related to the previous point: is rust-toolchain.toml needed for compiling librustc_codegen_spirv.so or for compiling shaders or for both?

Unfortunately the nightly toolchain is needed for compiling both. It all has to align. sigh

The good news is that with cargo-gpu, the shader crates themselves don't have to depend on a nightly, or spirv-builder.

[schell]

Also related to the above, am I understanding correctly that this project installs (or plans to install) Rust toolchains under the hood?

Yes, it installs toolchains and components.

I agree with you that this should probably be more explicit since these are pretty big downloads. Maybe we should take some confirmation from the user by default?

[schell]

Adding all the SpirvBuilder::new() builder pattern arguments as CLI arguments?

Yeah, that's probably a good thing to have. Good call.

[schell]

Running as a daemon using rust-gpu's builder.watch()

I know cargo watch is unmaintained, but that's what I use for this case, eg cargo watch -x 'gpu build ...'

[schell]

And how could I forget, @schell's very own optional naga validation code

Haha! 🙇

Well I did have this in cargo-gpu originally, but took it out because I didn't want to assume that anyone would want to use cargo-gpu this way. I'm also a bit wary of bloat, as well as the maintenance burden.

Also, it seemed more correct to have cargo-gpu generate a manifest containing all the shader endpoint names and paths, that way downstream projects could use this in their build scripts for this kind of tooling. I do this for my project renderling here. That script translates the .spv files into .wgsl files, validates them and then creates linkage/bindings as .rs files that are included in the main project. It works pretty well, I think.

[schell]

Lastly but not leastly - I'm looking forward to your contributions, @tombh ! Thank you!