We currently check that non-shader-visible heaps have a NULL
handle, but that doesn't seem to be guaranteed: beside WARP, also
NVIDIA drivers still return a valid pointer. And that's a pretty
useless check anyway; rather, check that shader-visible heaps
have a valid pointer, which is more interesting.
Currently the tests expect that creating buffers in COMMON or
COPY_SOURCE state on UPLOAD heaps or in COMMON state on READBACK
heaps leads to a failure. I tested WARP, AMD and NVIDIA, and in
all cases the operations is successful.
I think the D3D12 runtime used reject resources created in the
configurations detailed above, but it doesn't any more (both
using the latest Agility SDK and the runtime distributed with
an updated Windows 11 system). However the CI still uses an
earlier runtime, so the old behavior is still allowed as
broken.
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.
Some versions of Clang do not properly pass include paths to the
assembler when LTO is enabled. That's a problem for the DEMO_EMBED macro
used by the demos, since it relies on .incbin. To make matters even
better, compilation fails, but doesn't return an error code; the
resulting binary is simply broken. Fortunately we don't really care
about LTO for the demos, so we can simply disable it. See also
https://github.com/llvm/llvm-project/issues/112920
Thanks to Giovanni for tracking down some of the pieces of this issue.
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.
