- 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.
That seems reasonable to me.
- 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?)
Oh, I wasn't aware that GL had scaled-float formats. Reading the documentation... it appears that's what happens if you use glVertexAttribPointer() [not glVertexAttribIPointer()] with GL_INT but leave "normalized" as FALSE.