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 Investigate rustup component for cargo-gpu #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!

[tombh]

• @LegNeato That makes more sense then that there are bigger plans for the cargo gpu namespace 😏 And hopefully that bevy-rust-gpu dev responds soon!

• I tend to prefer the latter case you mentioned, where a standalone cli program compiles the shaders.

  @schell Go Team CLI haha. This leads on to a whole other topic: documentation. Maybe I can start a thread on Discussions, but what do you think about documenting cargo gpu build as the recommended method for compiling shaders?

• I see that building rustc_codegen_spirv from scratch on my machine (an M1 Macbook Pro) takes ~1.5 minutes.

  Yeah, I don't mind that first-time compile delay so much, would be great to avoid it, but that'd be just a nice-to-have.

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

  As in compiling shaders for CPU doesn't require nightly?

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

  What do you think about removing SpirvBuilder::watch() then? I see Bacon is the new recommended watcher, maybe we suggest that in the docs?

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

  The main point for me is the relationship rust-gpu has with wgpu and therefore naga. I know it's not the only way of consuming the final SPIRV shaders (ie ash, etc), but wgpu is the de facto Rust library for talking to graphics cards. And it seems to me that naga is somewhat lagging behind in its SPIRV support. There is of course wgpu::Features::SPIRV_SHADER_PASSTHROUGH but that's presented as a workaround and hopefully something that will one day no longer be needed, once naga catches up. As things stand at he moment I actually think it'd be best for rust-gpu to recommend SPIRV_SHADER_PASSTHROUGH as the default, I've just had too many problems with naga's SPIRV support. But that seems a shame, that it dissuades users for reporting naga shortcomings, and undermines best practices around validation. In conclusion I think what I'm trying to say is that it'd be great if there was a more explicit story around validation in rust-gpu. It's fine to have rough edges, just as long as the current state of affairs is acknowledged and best practices and workarounds are well supported and documented.

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

  Woah, that's awesome! But you don't feel that'd be appropriate to have that in rust-gpu somewhere? It wouldn't be possible to generate these .rs linkers in a generic way for say wgpu and ash?