Fix offscreen swapchain implicit synchronization#3062
Conversation
9c64ab8 to
cfee1ec
Compare
fabian-lunarg
added
the
approved-to-run-ci
cfee1ec to
0357fe8
Compare
0357fe8 to
cfee1ec
Compare
|
I don't understand, what changes are you requesting ? I updated the commit with all changes requested in comments. |
I reopened because from my perspective I did not see any codechanges. maybe a wrong commit got pushed? |
|
Oh, apparently there has been a git mess up. I will re-push the changes. |
no worries. but please, before just closing my open concerns, give me opportunity to verify the changes. |
|
Oh, okay, I thought marking conversation as resolved was the proper way to signal that I pushed modifications that should solve the issue. |
yes, for trivial concerns or one-liners normally not an issue (if there are actual changes). |
The offscreen swapchain needs to emulate the behavior of a WSI. In particular, this implies waiting for and signaling semaphores and fences on image acquisition and queue presentation. The behavior until now was to submit an empty workload as a queue submission waiting and signaling the correct synchronization primitives. While this works as expected for queue presentation, this introduces additional synchronizations for image acquisition. Indeed, image acquisition is queue independent, which means it doesn't need to wait for previous queue submissions to begin. By implementing it as an empty queue submit, we encounter cases where the implicit ordering constraints of Vulkan introduce a slowdown, making offscreen slower than onscreen. I have currently no solution for Windows and/or Mac (assuming they don't support `VK_KHR_external_semaphore_fd` and `VK_KHR_external_fence_fd`). However, on systems implementing these extensions (mainly Linux and Android systems), I propose to solve this using a technique inspired by Mesa's Vulkan WSI Layer: https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer The idea is to signal semaphores and fences by importing them as temporary file descriptor system handles using a predefined "invalid" value recognized as an "already signaled primitive". This behavior is described in the Vulkan specification for the `VkImportSemaphoreFdInfoKHR` and `VkImportFenceFdInfoKHR` structures (search for file descriptor value "-1"). Change-Id: I477a994baca34221b022e9f679c08fc1f260ab7b
cfee1ec to
67b93aa
Compare
|
Pushed. |
2 participants
The offscreen swapchain needs to emulate the behavior of a WSI. In particular, this implies waiting for and signaling semaphores and fences on image acquisition and queue presentation.
The behavior until now was to submit an empty workload as a queue submission waiting and signaling the correct synchronization primitives.
While this works as expected for queue presentation, this introduces additional synchronizations for image acquisition.
Indeed, image acquisition is queue independent, which means it doesn't need to wait for previous queue submissions to begin. By implementing it as an empty queue submit, we encounter cases where the implicit ordering constraints of Vulkan introduce a slowdown, making offscreen slower than onscreen.
I have currently no solution for Windows and/or Mac (assuming they don't support
VK_KHR_external_semaphore_fdandVK_KHR_external_fence_fd).However, on systems implementing these extensions (mainly Linux and Android systems), I propose to solve this using a technique inspired by Mesa's Vulkan WSI Layer:
https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer
The idea is to signal semaphores and fences by importing them as temporary file descriptor system handles using a predefined "invalid" value recognized as an "already signaled primitive".
This behavior is described in the Vulkan specification for the
VkImportSemaphoreFdInfoKHRandVkImportFenceFdInfoKHRstructures (search for file descriptor value "-1").