On Thu Feb 1 10:48:17 2024 +0000, Henri Verbeet wrote:
- I suspect I already know the answer to this one, but... If this is
all going to be d3d specific anyway... do we really care about having this in vkd3d-shader? Maybe not; perhaps it's fine for this to live in vkd3d-utils. Note though that instead of reporting this through vkd3d_shader_scan() we could also consider introducing e.g. a vkd3d_shader_parse_rdef() function, analogous to vkd3d_shader_parse_root_signature(). That probably wouldn't change the implementation much, but it would perhaps avoid the issue of this interface being a fair bit more specific to DXBC/D3D shaders than the rest of vkd3d_shader_scan().
After some thinking, I am not too convinced that touching vkd3d-shader is the right thing to do here. The "maximally purist" choice here might be to introduce vkd3d-shader-utils, for D3D-specific bits that do not need a Vulkan implementation, and honestly I don't even see that as excessively far-fetched (it's a few lines of Makefile and boilerplate after all, I think). However, leaving that aside, putting everything in vkd3d-utils currently sounds like the next best option. Hopefully the ABI and slight differences between d3dcompiler version problems can be abstracted away and bridged by appropriate small thunks in Wine, but I don't know much about them.