This is an alternative proposal to !5830. It fixes the same glitches in Horizon Zero Dawn, but attempts to do that by implementing the proper behavior expected from the swapchain. More precisely, it fixes a few mistakes I had made the last time I touched this code, it implements the frame latency waitable with a semaphore instead of an event (as it should be) and at last it uses the frame latency waitable to implement an appropriate wait after presentation when the client didn't request to manage the waitable directly.
This implementation is not yet complete, because the semaphore should be released when the frame is presented. Knowing when this is the case would require using `VK_KHR_present_wait`. We currently approximate that with the moment in which the frame is submitted for presentation to Vulkan, which as far as I can tell is good enough. Eventually I'll try to write the proper thing.
This MR depends on https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/1343, which has been submitted in the meantime to vkd3d. The vkd3d change is included in the first commit, so this MR is already functional.
--
v4: dxgi: Wait on the frame latency semaphore when the client doesn't do it.
dxgi: Make the frame latency waitable a semaphore.
dxgi: Remove the frame latency fence.
dxgi: Directly signal the frame latency fence.
dxgi: Do not bias the frame latency fence.
dxgi: Set the frame latency even when increasing the frame latency.
dxgi: Submit Vulkan presentation as soon as possible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7152
Startup and lock counts in native Windows are separate, and the lock count does not decrease when an async result is freed if the platform has been started.
--
v9: rtworkq: Do not cancel pending callbacks when closing a thread pool.
rtworkq/tests: Test queue shutdown with pending items.
rtworkq/tests: Test scheduled items.
mfplat/tests: Check for async result release after canceling work and shutting down.
mfplat/tests: Release callback2 in test_event_queue().
mfplat: Free the inner cookie passed to resolver_create_cancel_object().
rtworkq: Introduce an async result object cache.
rtworkq: Introduce a platform startup count.
rtworkq/tests: Test work queue.
mfplat/tests: Test platform startup and lock counts.
mfplat/tests: Test mixing of MF platform functions with their Rtwq equivalents.
mfplat/tests: Introduce a helper to check the platform lock count.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v5: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v4: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392
This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls).
By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout).
This [issue](https://bugs.winehq.org/show_bug.cgi?id=57849) gives a few examples of this causing significant degradation in the behavior of some games, which use alertable (server) waits for their FPS limiter.
--
v3: server: Use epoll_pwait2 if supported.
server: Convert to and use a timespec directly for timeouts if supported.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7392