Skip to content
This repository was archived by the owner on Oct 31, 2025. It is now read-only.
This repository was archived by the owner on Oct 31, 2025. It is now read-only.

Add support for using glam crate in shaders #134

Closed

Description

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

Activity

  1. bitshifter commented on Oct 25, 2020

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

  2. bjorn3 commented on Oct 25, 2020

    @bjorn3
    Contributor

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

  3. khyperia commented on Oct 26, 2020

    @khyperia
    Contributor

    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?

  4. bjorn3 commented on Oct 26, 2020

    @bjorn3
  5. repi commented on Oct 26, 2020

    @repi
    ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    c: spirv-stdIssues specific to the spirv-std crate

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions