There is a conflict between "scanning is an operation that should not depend on any external data"—which I still think is a fundamentally sensible position—and "scanning should make a best guess as to how the bindings will actually be used"—which also makes sense, or I wouldn't have proposed it in the first place.
Sure; that apparent conflict largely depends on the definition of "external" above though. I think it would be reasonable to consider the source and target information to be part of the abstract shader, as opposed to e.g. data contained in resources bound at runtime.
Or, perhaps more saliently, "scanning should be consistent with compiling".
Right.
- Allow passing VKD3D_SHADER_TARGET_NONE to vkd3d_shader_scan(). This satisfies the API consumer in me that is perpetually baffled by the fact that vkd3d_shader_scan() accepts a target type. If we receive NONE, we return whatever is fundamentally truest about the source type. In this case I think that means BLENDINDICES is FLOAT. This may end up also being the case if the target type is something nonsensical like SPIRV_TEXT or D3D_ASM...
Sure, that's fine with me. It's perhaps worth pointing out though that this may imply e.g. returning "VKD3D_SHADER_RESOURCE_NONE" as "resource_type" in "vkd3d_shader_descriptor_info" for D3D shader model 1 shaders if we're not going to consider source information either.
- We go ahead and automatically map BLENDINDICES to UINT if and only if compiling to SPIRV (or GLSL) and the environment is GL. [Or... should we do it for Vulkan too? The scaled-float formats exist, but are they as well-supported? Plus that'll require a pointless, albeit probably not destructive, round trip in the Vulkan driver.]
I don't think we need that. OpenGL (still) supports scaled-float formats. It could hypothetically be an issue when targetting d3d10+, e.g. when doing something like d3dbc->tpf/dxil. (Which makes me wonder... is this an issue ANGLE would have with translating GL to D3D?)
- If no environment is specified (environment is NONE or spirv_target_info is missing), we assume Vulkan. This is basically called out in the documentation anyway, but I figured I'd mention it for completeness sake.
Right, and in general the documentation for the source/target information structures should spell out the values used when those structures aren't present.
- Document that when the target type isn't NONE, we'll return a format that reflects how that target type will interpret the data. I think if we do this we don't actually have to say what that target type will be and under which conditions (or keep it constant across library versions?), although I certainly won't argue against doing that anyway.
Right, this is the main thing I've tried to argue for.