patrickhadlaw
commented
3 years ago Hey @jarble something that should probably be made more clear is that this crate is still heavily in development (rust to glsl translation is not yet implemented). But you raise a good point about Rust-GPU. I must've missed it when looking for a crate for rust to shader translation. Since that crate covers quite a bit of what the goal for this repository is I may have to rethink the scope of what this repo is trying to achieve (maybe just provide the extra features as an extension to Rust-GPU and utilize that crate's primitive shader types instead of reinventing the wheel).
Regarding closures and macros, again this repo is in early development stages so I haven't even thought about the ramifications of using those within a shader module.
I haven't looked into Rust-GPU very much but after a brief look it seems that it is intended to be used to compile standalone shader crates into spir-v binaries. That's actually an awesome repo which does a good portion of what this repo was made to do except the goal for this repo is to be able to compile the binaries from a procedural macro alongside your other code while allowing you to include other shader code and modules (original idea was other modules would be checked for shader definitions and if available would copy the glsl source or IR in front of the current shader's before compiling into binary). Also another goal for this repo was to autogenerate exported shader descriptor constructs from each shader module so, as an example, a game engine could provide a clean interface for binding data to the shader stage.
I'm gonna leave this issue open as a place to discuss the future of the repo.
It seems that the rhythmc-rs does not yet support closures or macros, but I found another Rust-to-SPIRV compiler that already supports them. Instead of re-implementing all of these features, could the rhythmc-rs compiler use Rust-GPU to compile Rust to SPIR-V?