The text here ties this fairly strongly to the input format, as well as the specifics of DXBC containers. I'm not going to object too much, but I'm not sure that's entirely warranted; I could imagine the the target format/API making a difference for what we return here, as well as compilation options. I could also imagine e.g. compiling HLSL to GLSL, and still wanting information about the input/output interface. Perhaps notably, the API tests here use HLSL as actual source.
I'm not really sure I understand this comment.
In the first place, yes, this is tied to DXBC, because vkd3d_shader_signature is very much based on DXBC. You can come up with something similar for other formats—as done in 2/2—but it requires inventing some degree of mapping (even for d3dbc it's not clear how semantic names or masks get mapped).
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.
I don't expect we'll ever support e.g. GLSL as source format, but note that the mapping there would be straightforward as well.
On the other hand, if we really wanted to do something specific to DXBC, we'd only need to expose some variant of shader_parse_signature(); we already have the API for the caller to extract the ISGN/OSGN/PCSG DXBC sections and their variants, and there would be no need to parse the shader's source in that case.
As an API consumer, I'd want it to be very clear what i/o variables are included in the shader or not (consider DXBC isn't exactly consistent about this: from an HLSL perspective, it seems arbitrary that pixel shader SV_Position is included in the signature but vertex shader SV_VertexID isn't) and how that mapping is done.
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 the second place, I don't understand how the target format affects anything. This is a scanning option, and it's currently implemented for vkd3d_shader_compile() only inasmuch as vkd3d_shader_compile() implicitly scans the source. If we want it to do something different, I think we need to work that out right now and document it.
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 think what you're trying to say is that we should put information about the GLSL (or Vulkan) binding here, but that seems to me like fundamentally a contradictory model to what we already have. Descriptor info doesn't work this way. If we want to provide feedback about the default mapping of varyings to the target format, and we can't rely on storing reflection data in that format (like with hlsl -> dxbc translation) I think we need to do that in some separate structure.
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.