Side note: maybe this should be a vkd3d_shader_parameter instead? I think it'd probably be good to lean in that direction, rather than adding more chained structures, for new compilation options like this. Mostly because it's easier to design and, I think, easier to use. It'll require rerolling vkd3d_shader_parameter which unfortunately can only have uint32_t in it, but we needed that anyway.
What would that look like? Shader parameters were roughly intended as the vkd3d-shader equivalent of SPIR-V specialisation constants; it would probably make sense to use them for e.g. spirv_compiler_emit_sample_position(), but it's less clear to me whether the interstage interface would be a great fit.
That's the form of shader parameters, but I don't think it makes any statements about their function. I don't know exactly what the intent for the function was, but honestly I'm not sure I see a reason to limit it. It can just mean "any input parameter that reflects something about the source environment that the target type requires to be encoded in the shader".
That may mean that vkd3d_shader_parameter could in theory cover almost everything, but I'm not sure I see that as a bad thing. I mean, the thing about chained structures is that they're not exactly the easiest thing to work with, mostly when it comes to optionally adding them, or building helpers to construct the parameters. Arrays like vkd3d_shader_parameter are nicer.
It also seems like adding one parameter at a time via vkd3d_shader_parameter requires less boilerplate than adding one at a time via chained structs, and adding several at a time is less arbitrary.
FWIW, I was planning to make things like alpha test or flat shading into parameters as well... just to give an idea of what else we may have to reconsider if gonig a different direction.
As for what it would look like, well, for a vague diff that leaves out important pieces, something like
``` diff --git a/include/vkd3d_shader.h b/include/vkd3d_shader.h index cd569ce9..ba8a9a78 100644 --- a/include/vkd3d_shader.h +++ b/include/vkd3d_shader.h @@ -292,6 +292,8 @@ enum vkd3d_shader_parameter_type VKD3D_SHADER_PARAMETER_TYPE_UNKNOWN, VKD3D_SHADER_PARAMETER_TYPE_IMMEDIATE_CONSTANT, VKD3D_SHADER_PARAMETER_TYPE_SPECIALIZATION_CONSTANT, + VKD3D_SHADER_PARAMETER_TYPE_VARYING_MAPPING, + VKD3D_SHADER_PARAMETER_TYPE_ALPHA_TEST_FUNC,
VKD3D_FORCE_32_BIT_ENUM(VKD3D_SHADER_PARAMETER_TYPE), }; @@ -308,6 +310,8 @@ enum vkd3d_shader_parameter_name { VKD3D_SHADER_PARAMETER_NAME_UNKNOWN, VKD3D_SHADER_PARAMETER_NAME_RASTERIZER_SAMPLE_COUNT, + VKD3D_SHADER_PARAMETER_NAME_OUTPUT_VARYING_REMAP, + VKD3D_SHADER_PARAMETER_NAME_ALPHA_TEST_FUNC,
VKD3D_FORCE_32_BIT_ENUM(VKD3D_SHADER_PARAMETER_NAME), }; @@ -334,6 +338,8 @@ struct vkd3d_shader_parameter { struct vkd3d_shader_parameter_immediate_constant immediate_constant; struct vkd3d_shader_parameter_specialization_constant specialization_constant; + struct vkd3d_shader_varying_mapping varying_mapping; + enum vkd3d_shader_alpha_test_func alpha_test_func; } u; }; ```
and the data type could be UNKNOWN or we could, I suppose, add dedicated data types.
In this case not every parameter name can support every parameter type, and I can see why that would be distasteful. In that case I guess alpha ref could belong as a vkd3d_shader_parameter, and everything else would need to be relegated to chained structures. I don't feel that distaste personally, but I won't argue about it.