Sure, but I'm not sure that's necessarily an argument for tying this to DXBC. After this series, the only unsupported source format is HLSL, and I think it would be straightforward enough to support there as well. In terms of potential future formats, we'd definitely want this to support DXIL, and likewise for something like d3d-asm or dxil-asm.
It's not impossible, but I'm not sure it's trivial and obvious either. What goes in the register_index field? (Zero?) Should SV_ThreadID be mapped?
Well, we'd want it to return the same information as we'd get when first compiling to TPF or d3dbc and then scanning the resulting shader. (And the straightforward though perhaps not entirely optimal way to implement HLSL scans would of course be to do just that.) That does imply that e.g. the HLSL target profile may make a difference.
Sure, although I'd argue that what you actually want to know as a user of this API is either what setup you'll need to do in the target API to use this shader, or what interface the shader for the next stage needs to have. Note that the former may somewhat depend on the target format/API. For example, for SPIR-V/Vulkan the "rasterizer" (VKD3DSPR_RASTERIZER) register needs to be supplied explicitly, while that's implicit for TPF/d3d11.
In theory, sure. In practice, the information DXBC exposes doesn't really align with that. For one thing, I misremembered: SV_VertexID actually does go in the input signature, despite not actually hooking up to the target API in any way. On the other hand, SV_DispatchThreadID doesn't.
Right, but if anything, that seems to argue against just returning the parsed input/output signatures contained in the DXBC.
In any case, this is something I really want to be spelled out as an API consumer. There is no greater crime than vagueness.
I don't know; I think that over the years I've come to appreciate the fact that ambiguity is the glue that holds many things together. :)
Consider e.g. the earlier BLENDINDICES discussion; when targetting an API without _USCALED/_SSCALED formats, we may want to consider BLENDINDICES as UINT. I don't necessarily have a lot of good examples here, but I wouldn't want to rule the scenario out up-front either.
I'm not sure this kind of thing really belongs in the scan information. Honestly it just feels ugly to me to imply that scanning can depend on anything other than the shader itself.
I tend to think of vkd3d_shader_scan() as providing the information needed to use the shader in the target environment. (And note that the function fairly deliberately takes a vkd3d_shader_compile_info structure as its input.) For modern formats like TPF and DXIL that can largely be derived purely from the original shader source; for something like d3dbc there is a lot more implicit state (e.g., fixed-function fog state) provided by the environment, as I'm sure you've already encountered.
There may be value in providing information purely about the original shader in its original intended environment, and we could potentially support that in vkd3d_shader_scan() by supporting VKD3D_SHADER_TARGET_NONE as target, but it's not quite how vkd3d_shader_scan() is currently intended.
No, I think that's a misunderstanding. I'm mostly just suggesting that I think it would be fine for the documentation to be phrased in terms of something along the lines of "a description of the shader's input/output parameters", instead of something along the lines of "this thing we extracted from a DXBC blob, except when we didn't".
I don't think there's an issue with the vkd3d_shader_scan_signature_info structure itself, and I could live with the current text if needed.
Sure, I think I understand not wanting to marry the text to a specific output format. The problem is that anything less than that just isn't specific enough. I could probably reword it so that the *lede* isn't married to the output format, but at some point I think we really do need to specify how the signature was parsed or generated.
I don't necessarily have an issue with documenting that, although it does feel like documenting implementation details instead of documenting what's provided by the API.