Naga generates HLSL that doesn't satisfy WGSL's layout rules for global matCx2 matrices

[jimblandy]

When a uniform global variable has a matrix type, Naga generates HLSL code that misinterprets the bytes passed from the GPU.

In buffers shared with the host, WGSL stores matCx2<f32> matrices packed, with columns aligned on eight-byte boundaries, as appropriate for a vec2<f32>. However, HLSL stores all matrix rows aligned on 16-byte boundaries. To compensate for this, Naga generates HLSL that interprets the memory as a sequence of C float2 vectors, and then reassembles them into a matrix when they are loaded.

However, since Naga (following WGSL) used to require global variables to be Struct types, the HLSL back end only implements this hack for struct members. Now that Naga allows globals of any type, the HLSL back end needs to apply this hack in more places.

For example, Naga translates the following WGSL:

@group(0) @binding(0)
var<uniform> global_mat: mat3x2<f32>;

into the following HLSL:

cbuffer global_mat : register(b0) { float3x2 global_mat; }

This is incorrect: the latter is a series of three float2 vectors each followed by eight bytes of padding, whereas the former should be three vec2<f32> vectors packed into 24 bytes, without padding.

[jimblandy]

Note that this problem also arises with arrays of matrices:

@group(0)
@binding(0)
var<uniform> transform: array<mat4x2<f32>, 5>;

That currently is translated into the below:

cbuffer transform : register(b0) { float4x2 transform[5]; }

which is also incorrect.