RFC: `glam`-ification of `spirv-std`

[Firestar99]

How are people feeling on replacing all the trivial impl Vector<f32, 4> with a plain glam::Vec4?

pro:

• clearer to read
• functions returning V: Vector don't need any explicit declarations that it's a Vec2, in case of ambiguity:
  

  rust-gpu/crates/spirv-std/src/float.rs

  Line 225 in fb42c2b

  pub fn u16x2_to_vec2_unorm<V: Vector<f32, 2>>(int: u32) -> V {

contra:

• Both Vec3 and Vec3A impl Vector<f32, 3>, so you can't use them interchangeably anymore. We expect most people to use Vec3, and conversion is a trivial From::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

pub fn subgroup_broadcast_first<T: VectorOrScalar>(value: T) -> T {

[schell]

This is a nice simplification from my perspective, no need to make these more general than they need to be.

[LegNeato]

I thought we wanted to get away from requiring glam?

[Firestar99]

Vector has 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 probably impl spirv_std::Vector for 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 Vec3 and 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 as Matrix { 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 a Matrix<f32, U3, U1, ArrayStorage<T, 3, 1>> to Vector3<T> but the types would mismatch. So any solution would need to be placed at struct Matrix level.
  • We probably want an nalgebra specific solution (instead of a generic one)
• 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.