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.
We want to be able to remap input signatures based on the signature index, but
signature normalization both reorders the signature, and requires the old
register index, so add a new field for this.
In Shader Model 6 each signature element can span a range of register
indices, or 'rows', and system values do not share a register index with
non-system values. Inputs and outputs are referenced by element index
instead of register index. This patch merges multiple signature elements
into a single element under the following conditions:
- The register index in a load or store is specified dynamically by
including a relative address parameter with a base register index. The
dcl_index_range instruction is used to identify these.
- A register declaration is split across multiple elements which declare
different components of the register.
- A patch constant function writes tessellation factors. These are an
array in SPIR-V, but in SM 5.x each factor is declared as a separate
register, and these are dynamically indexed by the fork/join instance
id. Elimination of multiple fork/join phases converts the indices to
constants, but merging the signature elements into a single arrayed
element matches the SPIR-V output.
All references to input/output register indices are converted to element
indices. If a relative address is present, the element index is moved up
a slot so it cannot be confused with a constant offset. Existing code
only handles register index relative addressing for tessellation factors.
This patch adds generic support for it.
The practical effect this has is that we avoid potential trailing padding at
the end of DXBC blobs. Unfortunately this also means we need to be more
careful about using bytecode_get_size() to find the offset where subsequent
data would get written, although in many cases this follows a put_u32() call.
VKD3D_SM4_OP_DCL_RESOURCE currently has 1 for "dst_count", but NULL for
"dst". This is largely harmless because we never attempt to access the
destination register of VKD3DSIH_DCL instructions, but nevertheless not
quite proper.
