In some cases, the compiler decided to emit continue block first,
which invalidated the expressions used by the condition.
Parameters to functions can be evaluated in any order which caused
"random" behavior.
If we run on a system with Xcode installed to a default path, run Xcode
Metal shader compiler to validate the generated MSL shader.
This uncovers an issue in the existing MSL test - MSL backend currently
does not auto-assign attribute locations, which means that translating
GLSL shader without location layout produces an invalid MSL which
generates "error: 'attribute' index '0' is used more than once".
To extract a column from row-major matrix, we need to do a strided load one
component at a time. In this case flattened_access_chain_offset still returns
the offset to the first element, but the stride is equal to matrix stride
instead of vector stride.
For this to work, we need to pass matrix stride (and transpose flag) through,
similar to how matrix flattening works.
Additionally slightly clean up recursive flattened_access_chain structure -
specifically, instead of deciding mid-traversal that we need matrix stride
information, we can just pass the matrix stride through - for access chains
that end in matrix/vector this gets us what we need, and for access chains
that end in structs the flattened_access_chain_struct code will recompute
correct stride/transposition data to pass through further.
We currently only support access chains that end in a matrix by propagating
"needs transpose" flag upstream which flips the matrix multiplication order.
It's possible to support indexed extraction as well, however it would have to
generate code like this:
vec4 row = vec4(UBO[0].y, UBO[1].y, UBO[2].y, UBO[3].y);
for a column equivalent of:
vec4 row = UBO[1];
It is definitely possible to do so but it requires signaling the vector output
that it needs to switch to per-component extraction which is a bit more trouble
than this is worth for now.
Previously, we would generate parentheses proactively when generating
binary ops, however, this leads to uglier code and hits warnings in
compilers when used as a conditional.
The size of an array can be a specialization constant or a spec constant
op. This complicates things quite a lot.
Reflection becomes very painful in the presence of expressions instead
of literals so add a new array which expresses this.
It is unlikely that we will need to do accurate reflection of interface
types which have specialization constant size.
SSBOs and UBOs will for now throw exception if a dynamic size is used since it
is very difficult to know the real size.
- Only consider I/O variables if part of OpEntryPoint.
- Keep a safe fallback if #entry-points is 1 to avoid potentially
breaking previously working shaders.
