On 3/24/22 09:56, Henri Verbeet wrote:
From: Conor McCarthy cmccarthy@codeweavers.com
D3D12 supports signalling a fence to a lower value, while Vulkan timeline semaphores do not. On the GPU side this is handled by simply submitting the signal anyway, if a test for this passes on device creation, because working around this is impractical. For CPU signals the Vulkan semaphore is replaced with a new one at the lower value only if no waits and/or signals are pending on the GPU. Otherwise, a fixme is emitted.
Partly based on a vkd3d-proton patch by Hans-Kristian Arntzen (not including the handling of lower fence values).
The old implementation is used if KHR_timeline_semaphore is not available or GPU signals do not work for a lower value.
This is causing pretty much all vkd3d tests, including shader tests, to hang on my machine (radeonsi, with Mesa 22.0.0), with the following messages:
err:d3d12_command_queue_ExecuteCommandLists: Failed to submit queue(s), vr -4. d3d12:3729: Test failed: Failed to signal fence, hr 0x80004005.
Perhaps most damningly, immediately returning true from d3d12_is_timeline_semaphore_supported(), without actually performing the invalid signal, allows shader tests to run successfully [although test_gpu_signal_fence() is still broken]. I'll admit, I was doubtful of the prospect of intentionally violating the Vulkan specification...
I don't know all of the concerns here, but from a quick reading of the specification, I wonder if it would be possible to, say, map d3d12 values to Vulkan values, and ensure the latter are monotonically increasing?
Or, if that doesn't work for some reason, could we try to introduce a Vulkan extension that allows properly emulating d3d12 behaviour?