[PATCH vkd3d 1/2] vkd3d: Use Vulkan timeline semaphores for D3D12 fences.

[Zebediah Figura]

On 3/24/22 09:56, Henri Verbeet wrote:
> From: Conor McCarthy <cmccarthy at 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?