On Tue, 12 Apr 2022 at 22:48, Zebediah Figura zfigura@codeweavers.com wrote:
On 4/12/22 13:57, Henri Verbeet wrote:
On Tue, 12 Apr 2022 at 18:42, Zebediah Figura zfigura@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.