[spirv] Fix bug of CTBuffer DX memory layout with matrix

[jaebaek]

When a CTBuffer contains a matrix and we use FXC memory layout for it i.e.,
-fvk-use-dx-layout, the memory layout of the generated struct is different
from what FXC generates. FXC memory layout rule for matrices or array of
matrices are:

1. floatMxN means N float vectors and each vector has M elements.

• How to calculate size: 16 * (N - 1) + 4 * M bytes
• How to calculate offset:
  • If the size is greater than or equal to 16 bytes: the offset must be aligned to 16 bytes
  • Otherwise (less than 16): it cannot be split into multiple 16 bytes slots.
• For example, float2x3 has 16 * (3 - 1) + 4 * 2 = 40 bytes as its size. Since its size 40 bytes is greater than 16 bytes, it must be aligned to 16 bytes.

2. floatMxN[K] means an array of floatMxN with K elements.

• size: (K - 1) * N * 16 + 16 * (N - 1) + 4 * M
• offset:
  • If K > 1, it must be aligned to 16 bytes
  • If K == 1, it is the same with floatMxN.
• For example, the size of float3x2 foo[7]; is (7 - 1) * 2 * 16 + 16 * (2 - 1) + 4 * 3 = 220.

The non-trivial case is float1xN which is a matrix with N vectors and each vector has 1 element.
Its size should be 16 * (N - 1) + 4 based on the FXC memory layout rule.
For example, the size of float1x2 must be 20 in bytes, which means we want to put the first float value of
float1x2 at the offset 0 in bytes and the second float value at the offset 16 in bytes.
It means we must not generate it as a SPIR-V vector type because setting it as a SPIR-V vector results in
putting the first at the offset 0 in bytes and the second at the offset 4 in bytes.
In addition, we cannot set it as a SPIR-V matrix type because SPIR-V does not allow a matrix with a single
row and a vector with a single element.
The only available option is to set it as a SPIR-V array with ArrayStride 16.

Since we currently consider float1xN as an OpTypeVector and generate all SPIR-V code based on the assumption.
Changing the type of float1xN to OpTypeArray needs huge engineering costs to handle all the cases.
For example, in many places e.g., addition, subtraction, multiplication, we use OpVectorShuffle for float1xN because we consider it as OpTypeArray.

Our solution is to create two variables for CTBuffer including type1xN with FXC memory layout:

1. Original: One with correct subtypes and memory layouts i.e., OpTypeArray for type1xN
2. Clone: One with Private storage class i.e., without physical memory layout
   • OpTypeVector for type1xN as the current DXC does.

The Original variable is in charge of getting CTBuffer data from CPU.
We create a module initialization function to copy the Original variable to the Clone variable.
We insert OpFunctionCall for the module initialization function into all entry points.
We use the Clone variable for the CTBuffer in all places.

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.4760 completed (commit f9560a9200 by @jaebaek)

[ehsannas]

The non-trivial case is float1xN which is a matrix with N vectors and each vector has 1 element.
Its size should be 16 * (N - 1) + 4 based on the FXC memory layout rule.
For example, the size of float1x2 must be 20 in bytes, which means we want to put the first float value of
float1x2 at the offset 0 in bytes and the second float value at the offset 16 in bytes.
It means we must not generate it as a SPIR-V vector type because setting it as a SPIR-V vector results in
putting the first at the offset 0 in bytes and the second at the offset 4 in bytes.
In addition, we cannot set it as a SPIR-V matrix type because SPIR-V does not allow a matrix with a single
row and a vector with a single element.

This is terrifying 😨

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.4786 failed (commit 7247ed3234 by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.4792 failed (commit e2ff96cd17 by @jaebaek)

[jaebaek]

I want to update the unit tests but it is almost done.
The basic idea is to make a clone variable for CTBuffer with FXC memory layout rule.

The clone variable has the same type and memory layout with the one the current DXC generates for CTBuffer.
The clone variable will be used as the CTBuffer but it does not follow the correct FXC memory layout.

I create a module initialization function to copy the CTBuffer with the correct memory layout to the clone variable and add OpFunctionCall to the wrapper function of entry points.

Mostly this copy will be optimized out by spirv-opt.
I will update the unit tests only more next Monday.

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.1 failed (commit eaeb02ad29 by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.2 failed (commit 8406085935 by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.4 failed (commit 2970cadb3d by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.5 failed (commit 1165681c55 by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.7 failed (commit 993eabf668 by @jaebaek)

[AppVeyorBot]

❌ Build DirectXShaderCompiler 1.0.9 failed (commit 1011c00644 by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.10 completed (commit 1011c00644 by @jaebaek)

[jaebaek]

This will fix #3463

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.11 completed (commit 0f23667e57 by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.15 completed (commit 46f1c5eefc by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.17 completed (commit e138a15065 by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.18 completed (commit 7a86a0adc6 by @jaebaek)

[jaebaek]

Thank you for your code review.

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.29 completed (commit ff073e97ea by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.59 completed (commit 0faab2c3ee by @jaebaek)

[AppVeyorBot]

✅ Build DirectXShaderCompiler 1.0.60 completed (commit 8ff663d06d by @jaebaek)