[Git][wine/vkd3d][master] 4 commits: tests/shader_runner: Record HLSL todo/fail state for each shader model.

[Henri Verbeet (＠hverbeet)]

Henri Verbeet pushed to branch master at wine / vkd3d

Commits:
e91c07e1 by Elizabeth Figura at 2024-12-17T16:18:21+01:00
tests/shader_runner: Record HLSL todo/fail state for each shader model.

When a shader fails to compile for a range of versions, we want to validate that
we are correctly implementing that behaviour. E.g. if a feature requires shader
model 5.0, we should validate that it compiles correctly with 5.0 (which we do),
but also that it *fails* to compile with 4.1 (which we do not).

The obvious and simple solution is to simply run compile tests for each version.
There are, however, at least 12 versions of HLSL up to and including 6.0, at
least 10 of which are known to introduce new features. Shader compilation takes
about 10-15% of the time that draw and dispatch does, both for native and
(currently) vkd3d. Testing every version for every shader would add a
noticeable amount of time to the tests.

In practice, the interesting versions to test for most shaders are:

* At least one from each range 1-3, 4-5, and 6. It's common enough for the
  semantics of the HLSL to differ between bytecode formats, or for features to
  be added or removed across those boundaries.

* If the shader requires a given feature, we want to test both sides of the cusp
  to ensure we're requiring the same version for the feature.

In practice this is 3 or 4 versions, which is measurably less than the 12 we'd
otherwise be running.

In order to achieve this goal of testing only the 3 or 4 interesting versions
for a shader, we need to know what version is actually required for a feature.
This is encoded in the shader itself using e.g. [pixel shader fail(sm<5)].

This patch therefore implements the first step towards this goal, namely,
determining which versions succeed and fail, so we can figure out which ones are
interesting.

We could require the test writer to specify which versions are interesting ahead
of time (e.g. "for version in 2.0 4.1 5.0 6.0") but this is both redundant (and
there are a *lot* of tests that need some feature gate) and easy for a test
writer to get wrong by missing interesting versions.

- - - - -
067e6dee by Elizabeth Figura at 2024-12-17T16:24:00+01:00
tests/shader_runner: Test HLSL compilation in a separate pass.

Mainly in order to not waste time compile-testing the same version
more than once [as we do with e.g. the d3d11 and d3d12 runners, or
d3d12, GL, and Vulkan].

- - - - -
8fcbbfb8 by Elizabeth Figura at 2024-12-17T16:35:09+01:00
tests/shader_runner: Test versions where the compilation result changes.

Adjust the algorithm for deciding for which profiles to test compilation.

We first ensure that if the compilation result changes (most often as the result
of a feature introduced in a specific version), we test the versions immediately
on either side of the change, to validate that vkd3d-shader is emulating the
same version behaviour.

We then ensure that we are testing at least one version from each set of sm1,
sm4, and sm6.

- - - - -
27c77769 by Elizabeth Figura at 2024-12-17T16:37:41+01:00
tests: Use fail(sm<5) instead of [require] for uav-atomics.

- - - - -

14 changed files:

- tests/hlsl/cbuffer.shader_test
- tests/hlsl/object-parameters.shader_test
- tests/hlsl/object-references.shader_test
- tests/hlsl/register-reservations-profile.shader_test
- tests/hlsl/register-reservations-resources.shader_test
- tests/hlsl/sample-bias.shader_test
- tests/hlsl/sample-grad.shader_test
- tests/hlsl/sample-level.shader_test
- tests/hlsl/sampler-state.shader_test
- tests/hlsl/sampler.shader_test
- tests/hlsl/state-block-syntax.shader_test
- tests/hlsl/uav-atomics.shader_test
- tests/shader_runner.c
- tests/shader_runner.h

View it on GitLab: https://gitlab.winehq.org/wine/vkd3d/-/compare/de615609dc30cb8571e796bcd2a9d...