[PATCH vkd3d 4/4] vkd3d-shader: Introduce struct vkd3d_shader_hlsl_source_info.

[Henri Verbeet]

On Fri, 25 Sep 2020 at 20:48, Zebediah Figura <zfigura at codeweavers.com> wrote:
> On 9/25/20 11:35 AM, Henri Verbeet wrote:
> > On Fri, 25 Sep 2020 at 19:35, Zebediah Figura <zfigura at codeweavers.com> wrote:
> >> On 9/25/20 8:01 AM, Henri Verbeet wrote:
> >>> On Fri, 25 Sep 2020 at 03:00, Zebediah Figura <zfigura at 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.) 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.