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.
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.
DXIL handles are used to represent descriptors. Currently they are
translated to registers of the appropriate type (depending on the
descriptor type) and three indices. The first two indices are used
to represent the descriptor itself (through its signature and array
index), and are filled when the handle itself is created. The last
index is used with constant buffers to address the data inside the
buffer itself, and it goes unused with other descriptor types.
As currently implemented, however, registers for descriptors other
than constant buffers are still created with three indices, even if
the last one is useless and set to -1. In the interest of creating
more sensible VSIR code, this is now removed: DXIL handles are
created with just two indices; a third one is added when accessing
constant buffers, and nothing is changed for other descriptor types.
As the newly added documentation describes, this reroll serves two purposes:
* to allow shader parameters to be used for any target type (which allows using
parameters for things like Direct3D 8-9 alpha test),
* to allow the union in struct vkd3d_shader_parameter to contain types larger
than 32 bits (by specifying them indirectly through a pointer).
For tpf shader this would previously be a pointer into the original
shader code, and for d3dbc shaders we'd use static strings.
Unfortunately the dxil parser creates shader signatures where these
are pointers to metadata strings, and those go away when we call
sm6_parser_cleanup().
We could conceivably store a flag in the shader signature to indicate
whether shader_signature_cleanup()/vkd3d_shader_free_shader_signature()
should free the "semantic_name" field. It'd be a little ugly, and seems
unlikely to be worth it, but I'd be willing to be convinced.
