For an if block
if (cond)
{
<then_block>
}
else
{
<else_block>
}
We flatten it by first replacing any store instruction `v[[k]] = x`
in the then_block with the following:
1: load(v[[k]])
2: cond ? x : @1
3: v[[k]] = @2
Similarly, we replace any store instruction `v[[k]] = x` in the
else_block with the following:
1: load(v[[k]])
2: cond ? @1 : x
3: v[[k]] = @2
Then we can concatenate <then_block> and <else_block> together and
get rid of the if block.
More recent versions of the Vulkan/SPIR-V validation layers have started
to complain about our usage of "SequentiallyConsistent" in our SPIR-V
output. Specifically, VUID-StandaloneSpirv-MemorySemantics-10866 "Memory
Semantics with SequentiallyConsistent memory order must not be used in
the Vulkan API".
The SPIR-V specification says: "If the declared memory model is Vulkan,
SequentiallyConsistent must not be used." However, we're using the
GLSL450 memory model with SPIR-V 1.3, and "Vulkan" is not available
before SPIR-V 1.5.
The Vulkan specification says "Sequentially consistent atomics and
barriers are not supported and SequentiallyConsistent is treated as
AcquireRelease. SequentiallyConsistent should not be used." in the
"Shader Memory Access Ordering" section.
Those don't quite add up to the "... must not be used in the Vulkan
API", from the validation layers, but it does seem clear that
SequentiallyConsistent isn't actually supported. On the DXIL side, when
targetting SPIR-V with dxc, the generated SPIR-V uses the
"None"/"Relaxed" memory semantics. I wasn't immediately able to find a
reference for what seq_cst is supposed to mean in the context of DXIL,
but "None"/"Relaxed" does seem consistent with how the HLSL
atomic/interlocked intrinsics are expected to behave, as well as with
our behaviour for tpf shaders.
It's not obvious what this last remaining use of
sm6_parser_require_space() is preallocating space for, and that's as
good of a reason as any to get rid of it.
Only calls to sm6_parser_add_instruction() where we are using the
returned vkd3d_shader_instruction are checked for, since these return
values might cause NULL dereferences if unchecked.
Other calls to sm6_parser_add_instruction() can be left alone since the
error is still recorded via sm6->p.status.
We have a number of vsir operations which should take a signed type, but
which the DXIL parser currently emits unsigned types for. For example,
ISHR.
In the SPIR-V backend, we translate ISHR to OpShiftRightArithmetic,
which is specified as filling the most-significant bits of the result
with the sign bit of the "Base" operand. For an unsigned type, that
would technically be 0. In practice, implementations like radv/Mesa seem
to fill with the most-significant bit of the "Base" operand for unsigned
types, but arguably that could be considered a bug. Alternatively, the
wording in the specification is just unfortunate; SPIR-V does generally
take the position that signedness of operands should be irrelevant for
almost all operations. Either way, it seems best to avoid using
OpShiftRightArithmetic with unsigned types.
For a target like MSL, allowing ISHR to take an unsigned source operand
is just inconvenient; we'd have to introduce bitcasts to achieve the
desired behaviour, instead of simply using msl_binop().
