On 4/13/22 09:34, Henri Verbeet wrote:
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.
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...