Add support for using `glam` crate in shaders

[repi]

Goal

At Embark we use glam as our primary math library in our native and WASM code and are quite happy with it.

We want to bring up the crate in Rust GPU so it can be built and used with our new spirv-unknown-unknown target in the Rust GPU compiler backend, and once that works likely change the example shaders here to use it, or have separate ones that uses and tests it.

In our own Rust engine we plan to convert our shaders to Rust GPU from GLSL and want to use the same math crate on all sides, or at least be able to.

Bring up

I've talked briefly with @bitshifter (the glam maintainer) and he was open to the idea of support, but we'll have to see what is needed for it.

May be multiple issues to resolve in Rust GPU first in its early stage to get this to work, which is why we are tracking this on our side first here. Once have a first compiling shader we can open a draft PR on glam with it and use it as a git dependency from there. May also take time until it can be merged in and tested as part of glam mainline if non trivial changes are required (or to get it it compiling in glam CI).

@bitshifter do you have any additional thoughts or concerns about how we may approach this? We don't want to take up too much of our time and do think we have a bunch of stuff we need to try and fix first.

Alternatives

Also note that this work does not mean that glam should be the only or the de facto math library for shaders in Rust.

We hope that most Rust math crates could eventually have support and we'll likely also be interested in exploring specific adaptions to make it adapted and ergonomic for GPU and shader programming (like vector swizzles) or even Rust language changes. But it would be great to have a standard well-designed crate, that we already use, to focus on and bring up first to have as a base.

[bitshifter]

Hi @repi, I'm excited that you are taking glam along on this journey to bring Rust to GPU! Bringing the crates.io experience to shader authoring sounds great and allows other crates, including other math libraries, to innovate in this space.

Certainly working in your own fork to get things off the ground and drafting a PR sounds like a good approach. I don't have any immediate concerns. If there was a need to make breaking API changes it would be good to discuss those if that came up.

The other thing would be if it was possible to build and test GPU code on standard free CI infrastructure, if it wasn't it would make maintenance a bit trickier.

[bjorn3]

Mesa has support for software rendering using the llvmpipes backend. It should be possible to use this for testing.

[khyperia]

I just looked into this for two minutes, and wanted to throw in my two cents:

glam has a std feature, but it doesn't seem to do anything? adding in a #![cfg_attr(not(feature = "std"), no_std)] in glam's lib.rs makes many things fail, I think entirely missing math functions (like f32::sqrt).

So, how do we let glam compile under no_std, but still have access to functions like f32::sqrt?

My initial thought in #81 was to introduce intrinsics in spirv-std:

// slap this onto an f32 extension trait or something to make it easy to use
#[spirv(compile_this_function_as_an_intrinsic = sqrt)]
fn intrinsic_sqrt(x: f32) {
    #[cfg(we_are_on_cpu_and_have_std)]
    x.sqrt()
    #[cfg(otherwise)]
    panic!("should have been compiled to intrinsic")
}

but glam doesn't have access to spirv-std!

So: how does glam call sqrt in a way that both works for glam on the CPU, but also we can recognize the intrinsic and generate the proper instruction for it? I honestly don't know, maybe some common third-party library or something? this thingy?

[bjorn3]

glam uses the sqrt function implemented by libstd. This function calls into libm. The easiest way would be to intercept this call. It has a known symbol name.

Edit: missed the part about #![no_std].

[repi]

I've done some experiments with this in related areas @khyperia , let's sync up!