Most Vulkan drivers are happy to compile a pipeline with interstage
interface mismatches, even if the pipeline will be broken. Metal,
and therefore MoltenVK, instead doesn't and errors out immediately.
This allows the Vulkan runner to execute in environments which do
not support geometry shaders, most notably MoltenVK. In particular,
that enables SM<4 shaders to run in such environments
Since recent versions seem to have more features and possibly
fewer bugs it is useful to know what you're dealing with.
Currently the latest WARP drivers are distributed here:
https://www.nuget.org/packages/Microsoft.Direct3D.WARP
The used UAV formats are explicitly added in the [require] section of
every test that uses them.
Some of these tests were failing on Intel UHD graphics 770 because of
missing support for additional UAV load types, explicitly requiring
these formats allows these tests to be skipped.
Currently we are skipping compilation tests ([* shader] blocks) on
missing capabilities. This is not really necessary and it is useful to
test shader compilation even on machines that can't run these tests.
So, this commit moves the checks to the [test] blocks, skipping them
entirely when caps are not met.
To make the effects of enum test_action values more explicit, these
are renamed to TEST_ACTION_SKIP_COMPILATION and
TEST_ACTION_SKIP_EXECUTION.
The current default is r32g32b32a32 but it requires special support
which is not available on all GPUs, so it is not a very convenient
default.
Instead of changing the default making it different from RTV resoures,
the format is required to always be explicit for UAVs.
The exceptions are counter_buffer and buffers with "stride", which don't
require a format because it is already implied.
This is simply unnecessary and wastes time.
As part of this, simply remove the "all" directive. Only for a couple of tests
is it even potentially interesting to validate all pixels (e.g.
nointerpolation.shader_test), and for those "all" is replaced with an explicit
(0, 0, 640, 480) rect.
In all other cases we just probe (0, 0).
So, if there is an error or a trace on "[pixel shader]" or similar
blocks, they get reported in the line with the tag at the beginning of
the block and no on the line where the next block starts.
