In the projected case, (1.2, 0.5) divided by 2.0 results in (0.6, 0.25) as
effective coordinates. The 0.25 y-coordinate is well within the second row of
texels; that's fine. On the other hand, the 0.6 x-coordinate falls right
between the third and fourth column of texels. The test expects the fourth
column to be selected, but that's very fragile: neither 1.2 nor 0.6 can be
exactly represented as a 32-bit floating-point value, and it only takes a
single ulp to push things to the other side of the edge.
Constant numeric local variables can be used in places were literals are
expected if they're initialized with a static expression.
Storing such constant in ctx->static_initializers allows copy-prop to
handle such cases properly.
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;
}
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().
