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

[Henri Verbeet]

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.