Matrix4x3 v2

[Firestar99]

• impl Debug and Display
• document limitations
• verify abi layout in difftest (the only part that requires #380)

[LegNeato]

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

[LegNeato]

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

[Firestar99]

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

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

Lines 29 to 38 in 951a990

	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,
	}
	}

[Firestar99]

What? Never seen a DXC (the DirectX 12 shader compiler) error, could be some kind of wgpu bug or an env change due to github updating the runners? Just gonna retry seems like other PRs are failing as well...

wgpu error: Validation Error

Caused by:
  In Device::create_compute_pipeline, label = 'Compute Pipeline'
    Internal error: DXC compile error: Compute Shader:138:14: error: expected identifier
            [8][8] _value3[2][8][8] = _e378;
             ^
Compute Shader:138:17: error: expected identifier
            [8][8] _value3[2][8][8] = _e378;
                ^
Compute Shader:138:20: error: use of undeclared identifier '_value3'
            [8][8] _value3[2][8][8] = _e378;

[schell]

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

[Firestar99]

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.