It's hard to pinpoint exactly what's going wrong with these
tests. They seem to be related to atomics and GPU timestamps,
both categories that are known to have problems on MoltenVK in a
way or another; those failures clearly depend on a few factors
like the MoltenVK version, the macOS version and whether we're in
a virtual machine or not, but the exact dependency on those factors
is hard to describe (for example, in general the paravirtualized
device offered inside virtual machines has a lot more problems than
real devices, but I've seen tests, fixed all other conditions,
working on the paravirtualized device and not on the real device).
The only thing all tests in this batch have in common is that I've
never seen them fail on a Sequoia system, thus I've settled for
using just that as the bug_if() condition. Ultimately, wasting a
lot of time to get to the bottom of each single test failure is
pointless, and being able to mark the CI job as not allowed to
fail gives better regression protection than investigating each
of those. Also, I routinely run the tests on a Sequoia system, so
if these tests get broken this is going to be noticed anyway.
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.
I don't know the exact version that fixed this todo, but on the
same hardware this test was failing a couple of years ago, so
I presume something was fixed at some point. I am writing my
current driver version, but a lower one might turn out to be
sufficient.
We would like to allow overriding the soname of libvulkan, in which case the
tests and demos should respect that override.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Neither MinGW's nor Microsoft's <windows.h> includes <stddef.h>, either
directly or indirectly. Also, unlike GCC, Clang's <inttypes.h> does not
include <stddef.h>, either. "vkd3d_windows.h" does include <stddef.h>,
and this is why building for the host works, even with Clang.
Fixes cross compilation errors with Clang related to using offsetof(3).
Signed-off-by: Chip Davis <cdavis@codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For backwards compatibility. Newer vkd3d versions may report more
capabilities, but some of those may also require newer vkd3d APIs in order to
use them. That's an issue for a vkd3d user like Wine, where reporting more
capabilities may cause the application to try to use APIs that are not
implemented in that version of Wine.
Note that using ELF symbol versioning would have solved the issue for existing
binaries compiled against older versions of vkd3d, but not for older source
compiled against newer versions of vkd3d.
Users of vkd3d-utils should define VKD3D_UTILS_API_VERSION to the vkd3d
API version they wish to target.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
