Here I am just printing a trace message on the rare situation where
GL_MAX_CLIP_DISTANCES is less than we need.
The maximum in Direct3D is given by D3D#_CLIP_OR_CULL_DISTANCE_COUNT which
is 8, which seems expectable here.
Alternatively we could add a clip-distance capability and only enable
it if gl_maxClipDistances is >= 8.
Another potential problem is that OpenGL expects the gl_ClipDistance[]
array to be the same size on every shader it is declared, which is a
restriction I am not sure Direct3D has with its SV_ClipDistance
components.
Co-authored-by: Anna (navi) Figueiredo Gomes <agomes@codeweavers.com>
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.
Some test programs, particularly the shader runner, are built from
many different files nowadays, and a line number is relatively
cumbersome to use if you don't know which file that line comes from.
