Do we need this? And perhaps more importantly, if we do need this, do we need this right away? For the purpose of vkd3d-compiler and vkd3d, we can just use vkd3d_shader_parse_dxbc() now, without making this part of the public API.
I don't see how to get this info from `vkd3d_shader_parse_dxbc()` without parsing the returned chunk tags, which would belong in vkd3d-shader anyway. It's very convenient to just use `compile_info.source_type = VKD3D_SHADER_SOURCE_DXBC_AUTODETECT` in state.c.
Sure, you'd need something along the lines of shader_detect_dxbc_source_type(), but writing that in vkd3d (or e.g. somewhere under include/private so that it can be shared with vkd3d-compiler) isn't really any less convenient than writing it in vkd3d-shader.
Along a similar vein, does this add much over the existing autodetection we have in vkd3d-compiler?
It avoids failure of `get_source_type_info()` for `VKD3D_SHADER_SOURCE_DXBC_AUTODETECT`. It could be worked around but this is a simple fix.
Sure, but that's a consequence of introducing VKD3D_SHADER_SOURCE_DXBC_AUTODETECT in the first place.
In the current split it takes 17 patches just to reach the point where a pixel shader with const output will compile, and there are far more to come. Unless we know of a specific problem caused by adding autodetect to the public API I would rather continue toward SM 6 compilation being largely complete. Until we have that, issues like the granularity of specific warnings/errors emitted with vkd3d_shader_error() must also have low priority.
I certainly understand the desire to get this upstream sooner rather than later. But adding things to the public API doesn't help with that; we try to be careful about the API we add, because once we make a release containing that API we're effectively stuck with it. Autodetection is particularly tricky, because there are a lot of potential corner cases to worry about. For example, what should happen when a shader contains both SHEX and DXIL sections? How about if one or the other is present but invalid? From the point of view of vkd3d, should the supported feature level make a difference? What about Aon9 shaders? If we do want to add public API for this, I'd argue against VKD3D_SHADER_SOURCE_DXBC_AUTODETECT and instead for a function to enumerate the possible source types contained in a particular shader.