Repository navigation
RFC: glam-ification of spirv-std #393
Description
Activity
- changed the title
[-]`glam`-ification of `spirv-std`[/-][+]RFC: `glam`-ification of `spirv-std`[/+]on Sep 17, 2025 This is a nice simplification from my perspective, no need to make these more general than they need to be.
I thought we wanted to get away from requiring glam?
Reacted by Timur Tugushev and Rachel KnightVectorhas only ever been implemented for glam, no other vector library was ever properly supported:rust-gpu/crates/spirv-std/src/vector.rs
Lines 28 to 52 in de03e8d
/// Abstract trait representing a SPIR-V vector type. /// /// # Safety /// Implementing this trait on non-simd-vector types breaks assumptions of other unsafe code, and /// should not be done. pub unsafe trait Vector<T: Scalar, const N: usize>: VectorOrScalar<Scalar = T> {} macro_rules! impl_vector { ($($scalar:ty: $($vec:ty => $dim:literal),+;)+) => { $($( unsafe impl VectorOrScalar for $vec { type Scalar = $scalar; const DIM: NonZeroUsize = create_dim($dim); } unsafe impl Vector<$scalar, $dim> for $vec {} )+)+ }; } impl_vector! { f32: glam::Vec2 => 2, glam::Vec3 => 3, glam::Vec3A => 3, glam::Vec4 => 4; f64: glam::DVec2 => 2, glam::DVec3 => 3, glam::DVec4 => 4; u32: glam::UVec2 => 2, glam::UVec3 => 3, glam::UVec4 => 4; i32: glam::IVec2 => 2, glam::IVec3 => 3, glam::IVec4 => 4; } And in #380 we're moving towards an explicit
#[spirv(vector)]declaration that is currently tailor made for how glam vector types are declared. (In the future, it should probablyimpl spirv_std::Vectorfor that type as well).If we want to support other vector libraries as well, I suggest we make a tracking issue for each one we want. Then we can make real steps towards supporting them. Comparing how different libraries implement
Vec3and how difficult it would be to support:- glam:
struct Vec3 { x, y, z: f32 } - ultraviolet: easy, Vec3 like glam
- nalgebra: hard,
Vector3<T>is typedef'ed asMatrix { data: ArrayStorage([[T; 3]; 1]), _phantom: PhantomData }- our validation would need to be adjusted to support nesting and handling arrays as a
OpTypeVector - would need support for the T generic, since it may be a valid element type but might not
- it's a typedef and not a struct, that could complicate things. If we just redefine the typedef to a
OpTypeVector, rust allows you to cast aMatrix<f32, U3, U1, ArrayStorage<T, 3, 1>>toVector3<T>but the types would mismatch. So any solution would need to be placed atstruct Matrixlevel. - We probably want an nalgebra specific solution (instead of a generic one)
- our validation would need to be adjusted to support nesting and handling arrays as a
- any other vector lib I'm missing?
You can still use any of these vector libraries! You just can't pass them to any spirv intrinsics directly, you must manually convert them to glam vectors first, with crates like
mint.Reacted by Timur Tugushev- glam:
How are people feeling on replacing all the trivial
impl Vector<f32, 4>with a plainglam::Vec4?pro:
V: Vectordon't need any explicit declarations that it's aVec2, in case of ambiguity:rust-gpu/crates/spirv-std/src/float.rs
Line 225 in fb42c2b
contra:
Vec3andVec3AimplVector<f32, 3>, so you can't use them interchangeably anymore. We expect most people to useVec3, and conversion is a trivialFrom::from.Cases where we are generic on the vector element type, or element count, or both should remain as generic, eg:
rust-gpu/crates/spirv-std/src/arch/subgroup.rs
Line 336 in fb42c2b