On 9/25/20 12:57 PM, Henri Verbeet wrote:
On Fri, 25 Sep 2020 at 20:48, Zebediah Figura zfigura@codeweavers.com wrote:
On 9/25/20 11:35 AM, Henri Verbeet wrote:
On Fri, 25 Sep 2020 at 19:35, Zebediah Figura zfigura@codeweavers.com wrote:
On 9/25/20 8:01 AM, Henri Verbeet wrote:
On Fri, 25 Sep 2020 at 03:00, Zebediah Figura zfigura@codeweavers.com wrote:
- /**
* Optional pointer to another compiled shader. This parameter must point to* a valid shader if any of the following compilation options are used:* - VKD3D_SHADER_COMPILE_OPTION_HLSL_MERGE_UAV_SLOTS* - VKD3D_SHADER_COMPILE_OPTION_HLSL_PRESERVE_TEMPLATE_SLOTS* - VKD3D_SHADER_COMPILE_OPTION_HLSL_REQUIRE_TEMPLATE_MATCH* If none of the above options are used, this parameter is ignored.*/- struct vkd3d_shader_code secondary_code;
Does the secondary code need to be in any particular format?
Presumably D3DCompile2() only supports SM4-5 shaders here. We might want to support other things, but it's not obvious to me we'd want to account for a format other than the target type.
It's probably fine to specify it as DXBC_TPF (although, can't this also be used with DXBC_DXIL?), but note that that's not necessarily the same as the target type; compiling from HLSL to D3D_ASM or SPIRV_BINARY for example seems entirely legitimate to me. It may have to be defined in terms of the target profile.
Sure, I was thinking about "type" rather than "profile". There's no reason why you couldn't pass two different types here, but I guess it's not clear why you'd want to...
I can add a vkd3d_shader_target_type field if you think there's call for it, though; I don't feel that strongly.
We probably don't need a vkd3d_shader_target_type field, but the format does need to be specified in some way; if that simply means writing something along the lines of "For shader model 4 and 5 profiles `secondary_code' should be a DXBC_TPF shader; for shader model 6 profiles it should be a DXBC_DXIL shader." in the documentation, that's fine. (Hypothetically of course; we don't support shader model 6.)
Ah, sure, I see what you mean now.
Defining it in terms of the target type would potentially be problematic though. E.g., suppose you're compiling HLSL to SPIR-V. That would then require "secondary_code" to be SPIR-V as well. That may be reasonable enough for the user of the API, but for the implementation it would impose a requirement to parse SPIR-V and recover the required information from it.