[PATCH vkd3d 3/4] vkd3d-shader: Introduce HLSL compilation flags.

[Zebediah Figura]

On 9/25/20 8:00 AM, Henri Verbeet wrote:
> On Fri, 25 Sep 2020 at 03:00, Zebediah Figura <zfigura at codeweavers.com> wrote:
>> +enum vkd3d_shader_hlsl_compatibility_mode
>> +{
>> +    VKD3D_SHADER_HLSL_COMPATIBILITY_DEFAULT = 0,
>> +    VKD3D_SHADER_HLSL_COMPATIBILITY_BACKWARDS_COMPATIBLE = 1,
>> +    VKD3D_SHADER_HLSL_COMPATIBILITY_STRICT = 2,
>> +
>> +    VKD3D_FORCE_32_BIT_ENUM(VKD3D_SHADER_HLSL_COMPATIBILITY),
>> +};
>> +
> Hexadecimal, please. These seem poorly defined, I'd prefer for these
> to refer to some kind of version/standard, similar to the way that
> e.g. gcc has "-std=gnu99". As far as I'm concerned it would be fine
> for that to be something like VKD3D_SHADER_HLSL_COMPATIBILITY_HLSL24
> to refer to the version of HLSL in d3dx9_24, if that makes sense for
> HLSL.

Sadly, they are poorly defined :-/

As I'm sure you've guessed, they correspond to the D3DCompile() flags
D3DCOMPILE_ENABLE_STRICTNESS and
D3DCOMPILE_ENABLE_BACKWARDS_COMPATIBILITY. The latter essentially allows
SM1-3 operations [tex2D(), but I don't know any others offhand] to be
mapped to analogical SM4-5 operations (instead of producing an error). I
don't actually know what ENABLE_STRICTNESS does.

But I'm happy to just ignore all the flags until they're used; there's
no harm in it. It does make the "secondary_data" field a bit weird, but...

> 
>> @@ -105,6 +116,48 @@ enum vkd3d_shader_compile_option_name
>>      VKD3D_SHADER_COMPILE_OPTION_BUFFER_UAV  = 0x00000002,
>>      /** \a value is a member of enum vkd3d_shader_compile_option_formatting_flags. */
>>      VKD3D_SHADER_COMPILE_OPTION_FORMATTING  = 0x00000003,
>> +    /**
>> +     * If \a value is nonzero, do not validate the compiled shader for
>> +     * correctness. The default value is zero.
>> +     *
>> +     * This option is supported by vkd3d_shader_compile(). However, not all
>> +     * compilers support validation.
>> +     */
>> +    VKD3D_SHADER_COMPILE_OPTION_SKIP_VALIDATION,
>> +    /**
>> +     * Optimize the compiled code. \a value is an unsigned integer which
>> +     * describes the level of optimization to apply, and may be between 0 and 3
>> +     * inclusive. The flag VKD3D_SHADER_OPTIMIZE_FLAG_SKIP_OPTIMIZATION may
>> +     * be combined via bitwise OR in order to suppress optimization entirely.
>> +     */
>> +    VKD3D_SHADER_COMPILE_OPTION_OPTIMIZE,
>> +    /**
>> +     * If \a value is nonzero, treat warnings as errors. The generated messages
>> +     * are not changed (i.e. warnings are still flagged with the string
>> +     * "warning"), but vkd3d_shader_compile() will fail if any warnings are
>> +     * generated.
>> +     */
>> +    VKD3D_SHADER_COMPILE_OPTION_WARNINGS_ARE_ERRORS,
>> +
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_PACK_MATRIX_ROW_MAJOR,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_PACK_MATRIX_COLUMN_MAJOR,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_PARTIAL_PRECISION,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_FORCE_VS_SOFTWARE_NO_OPT,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_FORCE_PS_SOFTWARE_NO_OPT,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_NO_PRESHADER,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_AVOID_FLOW_CONTROL,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_PREFER_FLOW_CONTROL,
>> +    /** \a value is a member of enum vkd3d_shader_hlsl_compatibility_mode. */
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_COMPATIBILTY_MODE,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_IEEE_STRICTNESS,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_RESOURCES_MAY_ALIAS,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_ENABLE_UNBOUNDED_DESCRIPTOR_TABLES,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_ALL_RESOURCES_BOUND,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_EFFECT_CHILD_EFFECT,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_EFFECT_ALLOW_SLOW_OPS,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_MERGE_UAV_SLOTS,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_PRESERVE_TEMPLATE_SLOTS,
>> +    VKD3D_SHADER_COMPILE_OPTION_HLSL_REQUIRE_TEMPLATE_MATCH,
>>
>>      VKD3D_FORCE_32_BIT_ENUM(VKD3D_SHADER_COMPILE_OPTION_NAME),
>>  };
>>
> Nothing particularly objectionable about these, but we probably want
> to wait with introducing them until they're implemented. Also, we may
> want to start the HLSL specific options at some offset from the common
> options (e.g. 0x00010000), so that future common options  can still be
> grouped together with the existing ones. (And likewise for future HLSL
> options if we end up adding some options specific to e.g. SPIR-V
> output.)
> 

-------------- 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/829cdf74/attachment.sig>