Giovanni Mascellani (@giomasce) commented about include/vkd3d_shader.h:
{ VKD3D_SHADER_PARAMETER_NAME_UNKNOWN, VKD3D_SHADER_PARAMETER_NAME_RASTERIZER_SAMPLE_COUNT,
- VKD3D_SHADER_PARAMETER_NAME_CAPABILITY_INT64,
It's not completely obvious to me that a parameter is what is appropriate here (a parameter would, for instance, allow that data item to be a specialization constant, which does not make any sense here). Even if this is not technically a SPIR-V extension, it seems that the `extensions` array is more appropriate for defining which features are allowed by the execution environment. It's not even clear to me whether this is something that should be explicitly enabled: all the other SPIR-V capabilities do not require explicit user confirmation for vkd3d-shader to use them, I can't see why int64 is different. And, after all, if a shader requires it there is little that can be done: we either enable it or fail; so we could directly assume it's available and generate a shader, and the execution environment will then decide whether that shader is usable or not (though, to be honest, the same could be told of `EXT_DESCRIPTOR_INDEXING` and `EXT_STENCIL_EXPORT`). Accepting an input parameter mo stly seems to make sense when we can generate different code depending on whether some feature is available or not (as for `EXT_DEMOTE_TO_HELPER_INVOCATION`), which could even theoretically be the case for int64, but I don't think there is currently any intention to provide an alternative int64 implementation on top of int32.