We cannot be redefining struct types in this rule, only referring to already
defined types. Struct type definition is handled by named_struct_spec, which
complains if the type was defined at all, regardless of class.
This is motivated by SampleId, whose presence or absence determines whether a
fragment shader runs at sample frequency or not.
In HLSL, if SV_SampleIndex is declared but not used, this results in a signature
entry, but no dcl instruction (and a zero used mask in the signature entry).
Whether the shader will actually run at sample frequency is inconsistent. NVidia
does, AMD does not, and WARP does for d3d12 but not for d3d11.
Previously vkd3d-shader relied on the dcl instruction, thereby aligning with
AMD. This was changed by 66cb2815f0. This commit
restores the previous behaviour.
sm6_metadata_get_float_value() already calls sm6_value_is_constant()
itself, and some compilers (rightly) emit a warning that the conversion
of UINT_MAX to float changes the value.
And other related identifiers similarly.
Currently we use VALUE_TYPE_ICB to indicate a raw chunk of data
(which can be used as an immediate constant buffer, but also for
initializing an indexable temporary) and VALUE_TYPE_REG with
register type VKD3DSPR_IMMCONSTBUFFER to indicate an actual ICB
register.
Since we are now switching to represent the register type directly
in the SM6 value, it seems sensible to use VALUE_TYPE_ICB for an
ICB register. Indeed, since what we're currently describing with
VALUE_TYPE_ICB is not necessarily related to an ICB register, it
makes sense to use a more general name, which is therefore being
introduced with this commit.
VALUE_TYPE_UNDEFINED means that a value is explicitly undefined,
equivalently to what was first represented with is_undefined.
VALUE_TYPE_INVALID will be introduced for values that arise from
invalid programs.
