[PATCH vkd3d 4/4] tests: Introduce a Vulkan shader runner.

[Henri Verbeet]

On Wed, 13 Apr 2022 at 20:02, Zebediah Figura <zfigura at codeweavers.com> wrote:
> It doesn't seem like the most intuitive API (e.g. it's kind of weird
> that you can scan DXBC but not SPIR-V, or that you can get information
> when compiling to SPIR-V but not when reflecting it), but I guess it
> makes sense regardless. I'll make sure to make the documentation clear...

The API doesn't prevent us from scanning/reflecting SPIR-V though; the
issue is that (in principle) SPIR-V doesn't have semantic strings.
Those originate from the HLSL source; DXBC retains those in the form
of the input/output signature, while SPIR-V does not. Indeed, the
whole reason we're scanning the HLSL/DXBC in the first place here is
because matching inputs doesn't work that way in Vulkan.

It may be possible to add some extra information to the SPIR-V as an
OpSource block, but it doesn't seem an especially attractive option.
The other way to do this is to make use of knowledge about HLSL input
assignment rules; in principle these are predictable, although I don't
think HLSL explicitly guarantees that anywhere.

Taking a step back and looking at the bigger picture, there are some
other ways to approach this as well. We could explicitly specify the
mapping from HLSL input semantics to SPIR-V attribute locations at
compile time, instead of using reflection to determine this after the
fact. This would look similar to what we do for resource/descriptor
bindings with the vkd3d_shader_interface_info structure. That seems
like a useful feature regardless of what we end up doing for the
shader runner.