There are two motivations for this:
* First, the structure *almost* corresponds to D3D12_SHADER_INPUT_BIND_DESC, and if more elements were included, it could be used as-is for shader reflection.
There is the quirk that currently we return scan information based on the shader instructions, whereas d3dcompiler shader reflection expects to get it from the shader reflection data (i.e. the RDEF chunk), which is particularly relevant in the case that the RDEF chunk is stripped.
That said, even if we have to introduce an extra scan API to account for this difference, being able to reuse the same structure seems like a benefit.
In order to reuse this structure, we need to add the following elements:
- Register ID (added in part 1 of this series)
- Sample count (added in part 2 of this series)
- Flags or resource types to distinguish between typed, raw, and structured buffers. I have not decided which representation makes the most sense; opinions are welcome.
* Second, I think it makes sense to use this reflection information internally in spirv.c (and potentially other compiler backends) to declare resources in the target environment, instead of parsing DCL instructions. The idea here is that this allows backends to be more agnostic as to how resources are declared (or inferred) in the frontend, while avoiding the need to synthesize those DCL instructions in the frontend either [especially since epenthesizing instructions is more expensive than converting them to NOPs.]
In order to do that, we will need vkd3d_shader_scan_descriptor_info1 to cover everything that is currently covered by DCL instructions. This needs the same elements as above (register ID and sample count), but also:
- Structure stride (added in part 2 of this series)
- Constant buffer used width (added in part 2 of this series)
I don't currently have a proof-of-concept using these new elements. On the other hand, since it's just an extension of an existing API, I figured that seemed less critical.
This does conflict trivially with 280; I'm submitting it now since 280 is accepted, but due to Alexandre's vacation may not be committed soon, and since this is new API I'd rather get comments early anyway.