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.
I haven't investigated the problem, but since the tests work for
other implementations and MoltenVK is not always perfect it's likely
that the problem is there.
They use geometry shaders, which MoltenVK doesn't support. However
D3D12 has no way to indicate they're unsupported, so the problem
doesn't surface as a failed draw, but rather as a draw that doesn't
do anything.
The expected λ value for the tests in question is about 0.59, which
after linear mipmap interpolation should result in a sampled value of
about 0.41. The quantisation step was added to allow results as high as
0.43, as seen on some implementations.
AMD Radeon Pro Vega 20 on macOS 15.5 returns a sampled value of about
0.39, with both Vulkan/MoltenVK and MSL/Metal. This is not an issue with
the bias calculation; the same behaviour could be reproduced with
SampleLevel(), as used in the sample-level tests, if those tests used
more exciting values for the "level" parameter. It also doesn't appear
to be a general Metal issue; Intel UHD Graphics 630 does return the
expected values on the same setup. Instead, this appears to be a mipmap
interpolation issue on this particular GPU/driver. Mapping the sampled
values for "level" from 0.0 to 1.0, it seems the interpolation factor
used is "saturate(frac(λ) * 1.25 - 0.125)", instead of the normal
"frac(λ)".
Fascinating as that may be, the test here mainly cares about whether the
bias value was applied correctly, and in that regard a sampled value of
0.39 isn't any worse than the 0.43 we already accept. This commit
adjusts the bias value so that the expected sampled value is 0.45, which
makes the accepted error the same on both the positive and negative
side.
They either use geometry shaders or cull distances, which MoltenVK
doesn't support. However d3d12 has no way to indicate they're
unsupported, so the problem doesn't surface as a failed draw,
but rather as a draw that doesn't do anything.
