On Wed, 13 Apr 2022 at 20:02, Zebediah Figura zfigura@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.