With some (Windows 11) runtimes creating a shader cache session fails
when the requested size is too small. The test will have to be fixed for
that, but in the meantime let's at least ensure it doesn't crash.
Compiling and running with UBSan reported the following errors:
tests/d3d12.c:31063:5: runtime error: index 4 out of bounds for type 'float [4][8]'
tests/d3d12.c:31063:5: runtime error: index 8 out of bounds for type 'float [8]'
tests/d3d12.c:31063:5: runtime error: load of address 0x557ee85a1500 with insufficient space for an object of type 'const float'
tests/d3d12.c:31248:5: runtime error: index 4 out of bounds for type 'float [4][4]'
tests/d3d12.c:31248:5: runtime error: index 4 out of bounds for type 'float [4]'
tests/d3d12.c:31248:5: runtime error: load of address 0x557ee85a10d0 with insufficient space for an object of type 'const float'
This used to work when the macOS runner had a Sonoma host system.
Now it has Sequoia, even if the guest is still Sonoma, and the
test crashes with:
[mvk-error] VK_TIMEOUT: MTLCommandBuffer "vkQueueSubmit MTLCommandBuffer on Queue 3-0" execution failed (code 2): Caused GPU Hang Error (00000003:kIOGPUCommandBufferCallbackErrorHang)
vkd3d:56072:err:vkd3d_wait_for_gpu_timeline_semaphore Failed to wait for Vulkan timeline semaphore, vr -4.
Upgrading MoltenVK or the guest to Sequoia doesn't seem to help.
I haven't investigated the problem, but my experience is that
the paravirtualized Metal driver has a number of problems.
We currently check that non-shader-visible heaps have a NULL
handle, but that doesn't seem to be guaranteed: beside WARP, also
NVIDIA drivers still return a valid pointer. And that's a pretty
useless check anyway; rather, check that shader-visible heaps
have a valid pointer, which is more interesting.
Currently the tests expect that creating buffers in COMMON or
COPY_SOURCE state on UPLOAD heaps or in COMMON state on READBACK
heaps leads to a failure. I tested WARP, AMD and NVIDIA, and in
all cases the operations is successful.
I think the D3D12 runtime used reject resources created in the
configurations detailed above, but it doesn't any more (both
using the latest Agility SDK and the runtime distributed with
an updated Windows 11 system). However the CI still uses an
earlier runtime, so the old behavior is still allowed as
broken.
It seems that the NVIDIA drivers leaves VBVs bindings untouched
when they are NULL (or the GPU buffer address is NULL), instead of
setting them to a null binding.
Differently from other cases of inconsistent behaviour between AMD
and NVIDIA, here I'm explicitly marking the NVIDIA behaviour as
broken, because the expected behaviour is spelled out explicitly
(at least for the D3D12 specification standards).
