An argument could perhaps be made that VKD3DSPR_COMBINED_SAMPLER is somewhat superfluous because the distinction between VKD3DSPR_COMBINED_SAMPLER and VKD3DSPR_SAMPLER is implied by the shader model, but I think the added clarity is helpful.
Yes. In general I rather like the idea of not making the API semantics depend on the shader model, at least inasmuch as it affects the output. I suppose in this case it's also redundant because sm1 uses different instructions (TEX et al.) but I still think the clarity is helpful here.
There's perhaps also an argument that we should describe how d3dbc descriptors are mapped to vkd3d-shader descriptors in the vkd3d_shader_scan_descriptor_info documentation, much like we do for d3dbc shader constants. The instructions for vkd3d_shader_resource_binding and vkd3d_shader_combined_resource_sampler would then logically fall out of that.
Yeah, I agree, this shouldn't be in two different places. I'll change this in v2.
vkd3d_shader_parser_error(), please. Conveniently, we already have VKD3D_SHADER_ERROR_VSIR_NOT_IMPLEMENTED.
Will do. There was precedent elsewhere but that one was my fault too, I'll add a patch to fix it.