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>
