Could we just provide accurate information from the point of view of the user of the API? I.e., provide the actual masks and data types the shader expects and uses?
I think so.
I'm not quite sure what that means in practice for BLENDINDICES; in wined3d we seem to map everything to WINED3D_TYPE_FLOAT, but it's not clear if that's correct because we have very little existing coverage for BLENDINDICES. But if e.g. Vulkan should pass the data for this as VK_FORMAT_R32_UINT, I think it should be UINT, yes.
I'm going off memory, but I think it's legal in d3d9 to use any data type in the vertex declaration. I think it's also legal for d3d11, even; i.e. there's no need to actually match the shader data type. In practice this means we hit Vulkan validation errors, which we'd need yet more interface data to avoid, and I believe these validation errors also matter (i.e. the driver will just bit-cast the data if the type doesn't match.)
So if my memory is correct in this respect, the vertex attribute type doesn't exactly matter. On the other hand, we can (as always) provide reasonable guesses, and UINT is the best reasonable guess for BLENDINDICES, so it does kind of seem like the most sensible thing to me.
Wrt wined3d, I haven't checked, but GL may implicitly do a proper cast?
I imagine we'll just want to move the function in the final version of this series and avoid the forward declaration.
Sure, I'll add an extra patch for that.
I think we should set the "register_count" field above. It will be largely unused for the moment, but vkd3d_shader_signature_from_shader_signature() will print a FIXME if it ends up being larger than 1.
Indeed; that was oversight while rebasing onto Conor's work.
Most of the FIXMEs should use vkd3d_parser_error()/vkd3d_parser_warning().
Sounds right.