Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 33 additions & 13 deletions crates/spirv-std/src/matrix.rs
Original file line number Diff line number Diff line change
@@ -1,31 +1,39 @@
//! a set of common SPIR-V Matrices, used for intrinsics

use core::fmt::{Debug, Display, Formatter};
use glam::{Affine3A, Mat3, Mat3A, Mat4, Vec3, Vec3A};

/// A Matrix with 4 columns of [`Vec3`], very similar to glam's [`Affine3A`].
///
/// Primarily used in ray tracing extensions to represent object rotation, scale and translation.
///
/// # Limitations
/// These Limitations apply to all structs marked with `#[spirv(matrix)]`, which `Matrix4x3` is the only one in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a bit too inward facing. Just state the limitations. I guess you can optionally ask for a task.

/// `spirv-std`:
/// * Cannot be used within buffers, push constants or anything that requires an "explicit layout". Use [`Affine3A`],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for my education - why don't we use one of these types instead? Or wrap one?

Copy link
Member Author

@Firestar99 Firestar99 Nov 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly effort vs value.

Whereas glam vectors are OpTypeVector types, Matrices are not OpTypeMatrix but regular OpTypeStruct with regular members, aka. N times VecN members. There's only very few operations in SPIR-V that actually accept an OpTypeMatrix: OpTranspose, OpMatrixTimesVector, OpVectorTimesMatrix, OpMarixTimesMatrix and OpOuterProduct. Instead of using those, we just emit regular code based on the glam implementations of the equivalent instructions, which is also what most hardware would do, so very low value in getting those to work. (AI workloads use CooperativeMatrix, an entirely different system.)

To get glam Matrices to be actual OpTypeMatrices, they'd need a very similar refactor to Vectors in #380 first. Cause their size and alignment, as vectors previously, is not defined by the rustc layouter but by whatever "intrinsic values" we define in the codegen, so you'd similarly get different sizes and alignments between GPU and CPU. And then they'd still be useless, since we'd need to wrap all the glam functions for matrices to emit the SPIR-V intrinsics instead of regular instructions, requiring another breakage in glam compatability. That's a lot of effort.

The raytracing extensions (ray query and ray pipeline) require a 4x3 Matrix, which doesn't exist directly in glam. It is semantically equivalent to an Affine3A except in layout, since that type is (Mat3A, Vec3A) but we need [Vec3; 4] (or Vec3A), so we need a custom type anyway. All that for literally two intrinsics, which I've never used since they are ray query and I've only played with ray pipelines (outside of rust-gpu):

  • get_candidate_intersection_object_to_world
  • get_committed_intersection_object_to_world

Prior to #391, these intrinsics "created" the Matrix type within their asm! block, extracted the vectors and returned either a [Vec3; 4] or [Vec3A; 4]. That got changed to this matrix type not just because it's more convenient, but also in preparation for #392, which disallows declaring OpTypeVector in asm! blocks, but we need those to declare the OpTypeMatrix. And that PR was a requirement for #380, the vector layout refactor, since there's no way to declare whether an asm OpTypeVector %f32 3 would be a Vec3 or a Vec3A. Instead the type is "imported" into the asm blocks via type inference (_) or an explicit typeof{type} / typeof*{type}, if necessary.

On top of that, there's very few people actually using them, at least I don't know of anyone currently. We still don't want to break ray tracing but it's not exactly a priority. So the minimal effort solution was to not bother touching SpirvType::Matrix at all, and just create a new type that works for those intrinsics. And explicitly warn people not to put them into any buffers, instead to convert them from / to glam types and read / write those.

/// [`Mat4`] or the combination of [`Mat3`] with [`Vec3`] instead and convert them to `Matrix4x3` in the shader.
/// * There may be other situations where this type may surprisingly fail!
#[derive(Clone, Copy, Default, PartialEq)]
#[repr(C)]
#[spirv(matrix)]
#[allow(missing_docs)]
pub struct Matrix4x3 {
pub x: Vec3A,
pub y: Vec3A,
pub z: Vec3A,
pub w: Vec3A,
pub x_axis: Vec3A,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did this change? Is it more or less consistent with other APIs?

Copy link
Member Author

@Firestar99 Firestar99 Oct 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More consistent, now the member names are the same of glam's matrices. Split it out into a separate commit to make it easier to reason about

impl Matrix4x3 {
/// Convert from glam's [`Affine3A`]
pub fn from_affine3a(affine: Affine3A) -> Self {
Self {
x_axis: affine.x_axis,
y_axis: affine.y_axis,
z_axis: affine.z_axis,
w_axis: affine.w_axis,
}
}

pub y_axis: Vec3A,
pub z_axis: Vec3A,
pub w_axis: Vec3A,
}

/// The `from_*` fn signatures should match [`Affine3A`], to make it easier to switch to [`Affine3A`] later.
/// The `to_*` fn signatures are custom
/// The `to_*` fn signatures are custom.
impl Matrix4x3 {
/// Convert from glam's [`Affine3A`]
pub fn from_affine3a(affine: Affine3A) -> Self {
Self {
x: affine.x_axis,
y: affine.y_axis,
z: affine.z_axis,
w: affine.w_axis,
x_axis: affine.x_axis,
y_axis: affine.y_axis,
z_axis: affine.z_axis,
w_axis: affine.w_axis,
}
}

Expand Down Expand Up @@ -53,11 +61,11 @@ impl Matrix4x3 {
pub fn to_affine3a(self) -> Affine3A {
Affine3A {
matrix3: Mat3A {
x_axis: self.x,
y_axis: self.y,
z_axis: self.z,
x_axis: self.x_axis,
y_axis: self.y_axis,
z_axis: self.z_axis,
},
translation: self.w,
translation: self.w_axis,
}
}

Expand All @@ -76,3 +84,15 @@ impl Matrix4x3 {
Mat4::from(self.to_affine3a())
}
}

impl Debug for Matrix4x3 {
fn fmt(&self, f: &mut Formatter<'_>) -> core::fmt::Result {
Debug::fmt(&self.to_mat4(), f)
}
}

impl Display for Matrix4x3 {
fn fmt(&self, f: &mut Formatter<'_>) -> core::fmt::Result {
Display::fmt(&self.to_mat4(), f)
}
}
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@ use core::mem::offset_of;
use core::ops::Range;
use experiments::*;
use spirv_std::glam::*;
use spirv_std::matrix::Matrix4x3;

pub struct BumpAlloc(usize);

Expand Down Expand Up @@ -61,6 +62,7 @@ pub fn eval_layouts(gid: u32, out: &mut [u32]) {
0x11 => write_layout!(out, offset, Struct0x11(a, b)),
0x12 => write_layout!(out, offset, Struct0x12(a, b, c, d, e)),
0x13 => write_layout!(out, offset, Struct0x13(a)),
0x14 => write_layout!(out, offset, Matrix4x3(x_axis, y_axis, z_axis, w_axis)),

// mat
0x20 => write_layout!(out, offset, Mat2()), // private members
Expand Down