[PATCH vkd3d 4/4] vkd3d-compiler: Default to HLSL as a source format when preprocessing.

Zebediah Figura (she/her) zfigura at codeweavers.com
Mon Nov 30 11:04:12 CST 2020


On 11/30/20 7:05 AM, Henri Verbeet wrote:
> On Fri, 27 Nov 2020 at 20:01, Zebediah Figura (she/her)
> <zfigura at codeweavers.com> wrote:
>> On 11/27/20 7:03 AM, Henri Verbeet wrote:
>>> On Thu, 26 Nov 2020 at 21:25, Zebediah Figura <zfigura at codeweavers.com> wrote:
>>>> -    if (!options.output_filename && get_target_type_info(options.target_type)->is_binary
>>>> -            && isatty(fileno(output)))
>>>> +    if (!options.output_filename && options.target_type != VKD3D_SHADER_TARGET_NONE
>>>> +            && get_target_type_info(options.target_type)->is_binary && isatty(fileno(output)))
>>>>      {
>>>>          fprintf(stderr, "Output is a tty and output format is binary, exiting.\n"
>>>>                  "If this is really what you intended, specify the output explicitly.\n");
>>> Perhaps we should test whether the source format is binary here with
>>> -E. Although it may not end up being very useful in practice, I don't
>>> think there's an inherent reason that vkd3d_shader_preprocess()
>>> couldn't be used with binary formats.
>>>
>> Maybe if it were something like m4, yeah, but the HLSL preprocessor is
>> very whitespace-sensitive. Although we could introduce a custom m4-like
>> preprocessor for other formats...
>>
> Sure, we could have different preprocessors for different formats. (Or
> even different preprocessors for the same format, if it came to that.)
> As far as vkd3d-compiler is concerned though, none of that should
> really matter; if "options.preprocess_only" is set, the format of the
> output is determined by "options.source_type".

Sorry, I managed to completely misunderstand what you were saying at
first. Now this comment makes sense, and I agree, we should check the
input format here instead.

> 
>> [Perhaps we should also add something like
>> vkd3d_shader_get_supported_preprocessor_types()?]
> Possibly, although at least initially we could probably get away with
> simply returning a copy of the input for source formats that do not
> have an inherent associated preprocessor.
> 

That's a good idea, actually; I hadn't thought of that. That does mean
that for backwards compatibility's sake there's not a lot of point in
later adding vkd3d_shader_get_supported_preprocessor_types().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0D9D358A07A17840.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201130/e96a3c4a/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20201130/e96a3c4a/attachment-0001.sig>


More information about the wine-devel mailing list