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.
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?
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.
It's not that I think this API needs to be specific to DXBC—far from it, the whole impetus for that patch is 2/2 which extends it to sm1—but I don't think we can just support every format right off the bat without nontrivial API design. I don't exactly want that to hold up sm1 support if there's not a good reason.
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 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.
In any case, this is something I really want to be spelled out as an API consumer. There is no greater crime than vagueness.
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'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 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.
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.