Right now the modern graphics APIs are moving towards using the SPIRV binary format as the default way to upload a shader to the GPU.
In some cases, an alternative format is used and the spirv_cross crate (a C++ wrapper) will convert that SPIRV into the alternative format.
As with all C/C++ wrapping crates, the biggest problem with using the crate is just getting the C part compiled in the first place. For as portable as C the language is, C the build process is one of the least portable things you can find around. When using these things as a crate, people need a pure Rust solution simply because that's the only way to ensure that cargo build will "just work" regardless of platform or local setup. The pure Rust version could provide the exact same abilities as the C version, and it would still be better simply because it would interact better with the rest of cargo's build process.
Javelin is a new project by the gfx-rs team to replace the spirv_cross functionality with a pure Rust version. Amazing, and I support them.
What we need is another project that does the same thing for the first part of the pipeline.
Shader Language --> SPIRV --> API Shader
Javelin replaces that second arrow in the pipeline with pure Rust. Right now that first arrow, converting some sort of textual shader language into SPIRV, doesn't have a pure Rust answer.
Now there's no single source language. SPIRV is just a format the same as LLVM IR is a format, and potentially anything can produce SPIRV if it wants. There are, however, two main shader languages that people are likely to be familiar with (or be able to find books about):
GLSL, used by OpenGL
HLSL, used by DirectX and Unity
The differences between these two languages are very superficial overall. There's automatic converters between the two for simple shader programs, and a small 30 minute tutorial is all that a person who knows one of them would need to learn the other.
So, what we need is: a crate that lets you convert a &str holding a shader program into the correct binary SPIRV data (Vec<u32>).
There's multiple shader stages in a complete rendering/compute pipeline. All stages must be supported.
The particular source language that's first supported by the crate is unimportant compared to having this crate at all, so this initial issue does not take a position as to which should be supported first.
Ideally, both languages would be supported eventually. Perhaps as one unified crate, perhaps as two separate crates. However is determined to be best by the compiler writers.
Ideally, once the crate has a solid lib form, it will also get a cli front end so that people can just install the cli program once and then they can run that as a stand alone thing. Many programs, perhaps even most programs, don't need to dynamically compile SPIRV at runtime, and a cli utility that can be run during a build script is sufficient for those programs.
Also, for any browsing this issue that aren't already aware of it, in terms of "Rust things that generate SPIR-V", rust-gpu generates SPIR-V from (a subset of) pure Rust code (using Rust as a shader language) and is already quite usable, though still early :)
Right now the modern graphics APIs are moving towards using the SPIRV binary format as the default way to upload a shader to the GPU.
In some cases, an alternative format is used and the
spirv_cross
crate (a C++ wrapper) will convert that SPIRV into the alternative format.As with all C/C++ wrapping crates, the biggest problem with using the crate is just getting the C part compiled in the first place. For as portable as C the language is, C the build process is one of the least portable things you can find around. When using these things as a crate, people need a pure Rust solution simply because that's the only way to ensure that
cargo build
will "just work" regardless of platform or local setup. The pure Rust version could provide the exact same abilities as the C version, and it would still be better simply because it would interact better with the rest ofcargo
's build process.Javelin is a new project by the
gfx-rs
team to replace thespirv_cross
functionality with a pure Rust version. Amazing, and I support them.What we need is another project that does the same thing for the first part of the pipeline.
-->
SPIRV-->
API ShaderJavelin replaces that second arrow in the pipeline with pure Rust. Right now that first arrow, converting some sort of textual shader language into SPIRV, doesn't have a pure Rust answer.
Now there's no single source language. SPIRV is just a format the same as LLVM IR is a format, and potentially anything can produce SPIRV if it wants. There are, however, two main shader languages that people are likely to be familiar with (or be able to find books about):
The differences between these two languages are very superficial overall. There's automatic converters between the two for simple shader programs, and a small 30 minute tutorial is all that a person who knows one of them would need to learn the other.
So, what we need is: a crate that lets you convert a
&str
holding a shader program into the correct binary SPIRV data (Vec<u32>
).