While so far it has been posible to do this at parse time, this must
happen after knowing if the complex cast is on the lhs or not.
The modified tests show that before this patch we are currently
miscompiling when this happens, because a complex lhs cast is transformed
into a load, and add_assigment() just stores to the generated "cast"
temp.
Vertex shaders do not have CMP, so we use SLT and MAD.
For example, this vertex shader:
uniform float4 f;
void main(inout float4 pos : position, out float4 t1 : TEXCOORD1)
{
t1 = (int4)f;
}
results in:
vs_2_0
dcl_position v0
slt r0, c0, -c0
frc r1, c0
add r2, -r1, c0
slt r1, -r1, r1
mad oT1, r0, r1, r2
mov oPos, v0
while we have the lower_cmp() pass, each time it is applied many
instructions are generated, so this patch introduces a specialized
version of the cast-to-int lowering for efficiency.
Otherwise ubsan reports runtime errors such as:
libs/vkd3d-shader/ir.c:4731:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Since we have -Wswitch, this forces the developer to update all relevant
switches when an enum case is added.
Places where the default is just a FIXME are left alone.
The previous names "not normalised" and "fully normalised" have meanings
which are likely to change with time. OTOH including a description of the
normalisation level in the enumerant seems excessive. Relating
normalisation levels to shader model versions might be a reasonable
compromise.
We normalize binary expressions by attempting to group constants
together, in order to facilitate further simplification of the
expressions.
For any binary operator OP, non-constants x, y, and constants a, b, we
apply the following rewrite rules:
a OP x -> x OP a, if OP is commutative.
(x OP a) OP b -> x OP (a OP b), if OP is associative.
(x OP a) OP y -> (x OP y) OP a, if OP is associative and commutative.
x OP (y OP a) -> (x OP y) OP a, if OP is associative.
Note that we consider floating point operations to be
non-associative.
The alternative to adding the vsir_program->tess_output_primitive and
vsir_program->tess_partitioning fields would be to emit the vsir
DCL_TESSELLATOR_OUTPUT_PRIMITIVE and DCL_TESSELLATOR_PARTITIONING
instructions, like DXIL does, but I think that the preference is to store
these kind of data directly in the vsir_program.
The combined sampler is created as a SAMPLER instead of a TEXTURE
because that fits all our current infrastructure. The only problem is
that in the CTAB it must appear as a Texture, so the new field
hlsl_type.is_combined_sampler is added.
Co-authored-by: Elizabeth Figura <zfigura@codeweavers.com>
Looking at the implementation of shader_sm4_read_dcl_sampler(), vsir
stores the resource index range both in
vkd3d_shader_instruction.declaration.sampler.range
and in the
vkd3d_shader_instruction.declaration.sampler.src.reg.idx[1-2]
indexes, so we do the same.
It is also worth noting that for shader models lower than 5.1, vsir
has a normalization on the ins->declaration src register indexes.
Refer to the following comment:
/* SM5.1 places a symbol identifier in idx[0] and moves
* other values up one slot. Normalize to SM5.1. */
on shader_sm4_read_param().
This normalization is also added to the generated vsir instructions.
