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

[Zebediah Figura]

On 4/13/22 09:34, Henri Verbeet wrote:
> On Tue, 12 Apr 2022 at 22:48, Zebediah Figura <zfigura at codeweavers.com> wrote:
>> On 4/12/22 13:57, Henri Verbeet wrote:
>>> On Tue, 12 Apr 2022 at 18:42, Zebediah Figura <zfigura at codeweavers.com> wrote:
>>>> Yes, although in this case we need to reflect the DXBC anyway, in order
>>>> to retrieve vertex attribute bindings.
>>>
>>> Well, we currently do, but I'm not sure that's a necessity. It
>>> shouldn't be too hard to get
>>> vkd3d_shader_scan()/vkd3d_shader_compile() to return
>>> input/output/patch signatures as well.
>>
>> We do want a way to scan signatures from DXBC shaders regardless.
>>
>> I'm not sure that helps us on the HLSL -> SPIRV front, though. I guess
>> the solution there is "assume that inputs are allocated in order, one
>> register per variable", which seems a bit tenuous but ends up working
>> out, both for the reference compiler, and for native d3dcompiler (and
>> for our DXBC -> SPIRV path.)
> 
> The trivial implementation could do something like the following:
> 
>      struct vkd3d_shader_scan_signature_info
>      {
>          ...
>          struct vkd3d_shader_signature *input;
>          struct vkd3d_shader_signature *output;
>          struct vkd3d_shader_signature *patch;
>      };
> 
> and when present, fill that with information from the intermediate
> DXBC in vkd3d_shader_scan()/vkd3d_shader_compile(). A more direct
> variant could generate that same information directly from the HLSL.

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...