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

[Zebediah Figura]

On 9/25/20 12:57 PM, Henri Verbeet wrote:
> 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.) 

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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200925/34e741a9/attachment.sig>