The validator checks that on normalized vsir I/O destination write masks
are always a subset of the element's write mask.
This is currently not always happening for FOG and PSIZE outputs, because
d3dbc input might use the 0xf mask instead, despite these semantics being
scalar.
Note that this problem is hidden when using varying mapping, because in
that case the vsir_program_remap_output_signature() pass, specifically
the remove_unread_output_components() function, fixes the write mask.
This fixes the assertion error
"sm4_generate_vsir_instr_expr Failed assertion: dst_type->e.numeric.type == HLSL_TYPE_BOOL"
which occurs when compiling the following HLSL shader using the ps_4_0 target profile:
uniform float4 x;
uniform bool b;
float4 main() : SV_Target
{
if (!b)
clip(x.x);
else
clip(x.y);
return x;
}
With some (Windows 11) runtimes creating a shader cache session fails
when the requested size is too small. The test will have to be fixed for
that, but in the meantime let's at least ensure it doesn't crash.
We're already using functions not made available through either
metal_common or metal_texture. This doesn't seem to be an issue for the
Metal shader runner, possibly because the "online" compiler includes the
required headers by default. In any case, including metal_stdlib should
make all of MSLib available.
When no descriptor mapping is specified, the backend will just
build the usual default mapping. Otherwise the explicit mapping
is used.
Once all backends support the explicit mapping, we'll be able to
handle generating the default mapping in the shader runner core
rather than having each backend implement its own algorithm.
So far only the d3d12 backend supports explicit descriptor
mapping.
MSL doesn't seem to have any special handling for undefined values,
differently from SPIR-V. Thus we just emit zeros.
UNDEF registers are sometimes created by the DXIL parser,
for example in sm6_parser_emit_composite_construct().
