When no descriptor mapping is specified, the backend will just
build the usual default mapping. Otherwise the explicit mapping
is used.
Once all backends support the explicit mapping, we'll be able to
handle generating the default mapping in the shader runner core
rather than having each backend implement its own algorithm.
So far only the d3d12 backend supports explicit descriptor
mapping.
This directive requires specific shader models to be tested for
compilation, bypassing the default behaviour where only one version from
each shader model set (SM1-3, SM4-5, SM6) is compiled.
Mostly to be able to associate a version number to each tag and
get rid of all the foo<1.2.3 tags. The new system also has fixed
tag slots, rather than dealing with strings, so we don't have to
manually adjust the size of the `tags' array.
With the new system each tag can be present or not, and if it is
present it can have an associated version number (of the form
major.minor.patch). If the version is not available, it is set to
0.0.0. Each tag can be queried for existence and for comparison
with the version number.
So we have a more recent version of SPIRV-Tools and also don't
have to recompile Mesa to test llvmpipe. This fixes a few failing
tests, but also breaks a couple.
Similar to how we have the "geometry-shader" cap. In principle shader
model 5+ implies support for tessellation shaders, but the Vulkan,
OpenGL, and Metal runners are able to support most of shader model 5+
without the underlying GPU (or API) necessarily supporting tessellation
shaders.
My main motivation to this is avoiding generating a lot of useless
log lines from other executors when I'm interested in just one of
them, but I can imagine this also somewhat improving efficiency.
Since this test depend on the specific code generated by the
native d3dcompiler we add the possibility to specify a "raw"
shader using a hex format. When the shader assembler is finally
available they should be replaced with assembly code.
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.
