vulkan-wsi-layer issueshttps://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues2024-01-25T12:24:07Zhttps://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/25Wayland WSI must not use presentation thread2024-01-25T12:24:07ZDaniel Stonedaniel@fooishbar.orgWayland WSI must not use presentation threadPer the [`VK_KHR_wayland_surface` spec](https://registry.khronos.org/vulkan/specs/1.3-khr-extensions/html/chap30.html#platformCreateSurface_wayland):
> Some Vulkan functions may send protocol over the specified wl_display connection when...Per the [`VK_KHR_wayland_surface` spec](https://registry.khronos.org/vulkan/specs/1.3-khr-extensions/html/chap30.html#platformCreateSurface_wayland):
> Some Vulkan functions may send protocol over the specified wl_display connection when using a swapchain or presentable images created from a `VkSurfaceKHR` referring to a `wl_surface`. [...] Also, calling `vkQueuePresentKHR` will result in Vulkan sending `wl_surface.commit` requests to the underlying `wl_surface` of each The `wl_surface.attach`, `wl_surface.damage`, and `wl_surface.commit` requests **must** be issued by the implementation during the call to `vkQueuePresentKHR` and **must** not be issued by the implementation outside of `vkQueuePresentKHR`. This ensures that any Wayland requests sent by the client after the call to `vkQueuePresentKHR` returns will be received by the compositor after the `wl_surface.commit`.
This isn't just a theoretical concern: in particular resize is completely broken if this requirement is violated.
It does make it really hard to usefully implement FIFO - everyone has tacitly agreed to just break the requirement that QP/ANI not block for ridiculous amounts of time in order to implement it - but we have [commit-queue-v1](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256) and [commit-timing-v1](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248) underway to make that work properly, and expect that everyone will support it very quickly.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/23Headless surface mode crashes at acquireNextImage2023-11-08T11:55:19ZjianmenghuangHeadless surface mode crashes at acquireNextImageI use vulkan-wsi-layer to support the VK_EXT_headless_surface, and use cmake . -DUSE_HEADLESS=ON to builed a headless version triange from https://github.com/SaschaWillems/Vulkan. However, it failed at acquireNextImage from the swapchain...I use vulkan-wsi-layer to support the VK_EXT_headless_surface, and use cmake . -DUSE_HEADLESS=ON to builed a headless version triange from https://github.com/SaschaWillems/Vulkan. However, it failed at acquireNextImage from the swapchain.
Here is the output:
Fatal : VkResult is "ERROR_INITIALIZATION_FAILED" in /home/xxx/vulkan_examples/Vulkan/examples/triangle/triangle.cpp at line 350
triangle: /home/xxx/vulkan_examples/Vulkan/examples/triangle/triangle.cpp:350: void VulkanExample::draw(): Assertion `res == VK_SUCCESS' failed.
Aborted (core dumped)
Here is the logs of setting ENABLE_VALIDATION true:
ERROR: [459314243][VUID-VkImportSemaphoreFdInfoKHR-handleType-07307] : Validation Error: [ VUID-VkImportSemaphoreFdInfoKHR-handleType-07307 ] Object 0: handle = 0x95a125000000001a, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x1b609443 | vkImportSemaphoreFdKHR(): handleType is VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT so VK_SEMAPHORE_IMPORT_TEMPORARY_BIT must be set, but flags is 0x0 The Vulkan spec states: If handleType refers to a handle type with copy payload transference semantics, flags must contain VK_SEMAPHORE_IMPORT_TEMPORARY_BIT (https://vulkan.lunarg.com/doc/view/1.3.243.0/linux/1.3-extensions/vkspec.html#VUID-VkImportSemaphoreFdInfoKHR-handleType-07307)
Fatal : VkResult is "ERROR_INITIALIZATION_FAILED" in /home/xxx/vulkan_examples/Vulkan/examples/triangle/triangle.cpp at line 350
triangle: /home/xxx/vulkan_examples/Vulkan/examples/triangle/triangle.cpp:350: void VulkanExample::draw(): Assertion `res == VK_SUCCESS' failed.
Aborted (core dumped)
After adding the following code, the sample still crashes at the same place (failed at acquireNextImage from the swapchain).
```
diff --git a/wsi/swapchain_base.cpp b/wsi/swapchain_base.cpp
index 4e46f2b..7041072 100644
--- a/wsi/swapchain_base.cpp
+++ b/wsi/swapchain_base.cpp
@@ -430,6 +430,7 @@ VkResult swapchain_base::acquire_next_image(uint64_t timeout, VkSemaphore semaph
info.sType = VK_STRUCTURE_TYPE_IMPORT_SEMAPHORE_FD_INFO_KHR;
info.semaphore = semaphore;
info.handleType = VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT;
+ info.flags = VK_SEMAPHORE_IMPORT_TEMPORARY_BIT;
info.fd = already_signalled_sentinel_fd;
}
```
See also: https://github.com/SaschaWillems/Vulkan/issues/1051 where this issue startedhttps://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/22Possibly remove the dependency of expicit-sync2022-08-23T09:48:18ZQingPossibly remove the dependency of expicit-syncVulkan WSI layer now requires `zwp_linux_explicit_synchronization_v1_interface`.
However, explicit-sync is only provided by weston. For other compositors like KWin or mutter, it is not available.
This makes the vulkan-wsi-layer not compa...Vulkan WSI layer now requires `zwp_linux_explicit_synchronization_v1_interface`.
However, explicit-sync is only provided by weston. For other compositors like KWin or mutter, it is not available.
This makes the vulkan-wsi-layer not compatiable with Kwin or mutter, which are actually used more widely than weston in real world.
Is it possible to remove the dependency of `zwp_linux_explicit_synchronization_v1_interface` for better compatibility?https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/21Possible race condition during AcquireNextImage2022-02-10T14:11:15ZDavid Harvey-MacaulayPossible race condition during AcquireNextImageIn `AcquireNextImage`, the layer uses `QueueSubmit` to signal semaphores and fences on the queue provided by `GetDeviceQueue`. There are no synchronisation
constraints on this queue, therefore there is a potential race condition if
the a...In `AcquireNextImage`, the layer uses `QueueSubmit` to signal semaphores and fences on the queue provided by `GetDeviceQueue`. There are no synchronisation
constraints on this queue, therefore there is a potential race condition if
the application intends to write to the same queue on a different thread during `AcquireNextImage`. This method of signalling may also impose a performance penalty as semaphores and fences will not be signalled until all work on the queue has completed.
Merge request #56 addresses both concerns by instead signalling semaphores and fences using the `VK_KHR_external_semaphore_fd` and `VK_KHR_external_fence_fd` extensions respectively. Where support for these extensions does not exist in the ICD, the layer will fallback to the aforementioned `QueueSubmit` method instead.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/19Image layout transitions2021-11-30T15:47:04ZMatteo FranchinImage layout transitionsThe Vulkan specification for VK_KHR_swapchain defines the `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR` layout for swapchain images. The Vulkan specification requests that applications transition swapchain images to this layout before calling `vkQue...The Vulkan specification for VK_KHR_swapchain defines the `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR` layout for swapchain images. The Vulkan specification requests that applications transition swapchain images to this layout before calling `vkQueuePresentKHR` and transition away from this layout after calling `vkAcquireNextImageKHR`, see https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkImageLayout.html.
The Vulkan WSI Layer must ensure that these layout transitions are not reaching the underlying ICD, as the ICD is not expected to be able to handle the transition. In particular, the `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR` may be an unknown layout to the ICD, as it is introduced in the VK_KHR_swapchain extension that the ICD is not required to implement.
Changing the Vulkan WSI Layer so that it handles the layout transitions is under investigation. At present, the Vulkan WSI Layer requires the ICD to handle the `VK_IMAGE_LAYOUT_PRESENT_SRC_KHR` layout similarly to `VK_IMAGE_LAYOUT_GENERAL`.
Note that having the Vulkan WSI Layer handle the layout transition is important to take advantage of swapchain image optimizations, such as [Transaction Elimination](https://www.arm.com/why-arm/technologies/graphics-technologies/transaction-elimination).https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/18Multiple ICDs support2022-03-01T18:47:02ZMatteo FranchinMultiple ICDs supportOne of the [goals of the Vulkan Loader](https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderInterfaceArchitecture.md#goals-of-the-loader) is to manage the Installable Client Drivers (ICDs) present in the system. [The Vul...One of the [goals of the Vulkan Loader](https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderInterfaceArchitecture.md#goals-of-the-loader) is to manage the Installable Client Drivers (ICDs) present in the system. [The Vulkan loader architecture](https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderInterfaceArchitecture.md) and implementation shield Vulkan applications as well as the Vulkan ICDs from the complexity of having multiple drivers accessible via a single Vulkan API.
Unfortunately, Vulkan layers can find themselves handling some of this complexity themselves. In particular, a Vulkan layer wanting to implement a Vulkan extension, such as the Vulkan WSI Layer, has to intercept a number of instance and device commands. In some circumstances, it is not straightforward for the layer to decide whether it should handle the call itself or it should rather hand it over to the loader and the ICDs.
For this reason, it is not trivial to guarantee that the Vulkan WSI Layer works smoothly in the case where multiple ICDs are installed in the system. Extensive testing would need to be put in place to ensure various multiple ICDs scenarios are working as expected. Such extensive testing has not been put in place, yet.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/8Double check the layer conforms to all of the LunarG layer conventions and rules2019-06-05T11:56:22ZBryan Law-SmithDouble check the layer conforms to all of the LunarG layer conventions and rulesThese are listed here:
https://vulkan.lunarg.com/doc/view/1.0.57.0/windows/LoaderAndLayerInterface.html#user-content-layer-conventions-and-rules
We should double check the layer is conformant here.These are listed here:
https://vulkan.lunarg.com/doc/view/1.0.57.0/windows/LoaderAndLayerInterface.html#user-content-layer-conventions-and-rules
We should double check the layer is conformant here.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/6The layer should be able to be either implicitly enabled or explicitly enabled2019-06-05T11:53:10ZBryan Law-SmithThe layer should be able to be either implicitly enabled or explicitly enabledCurrently, the layer has only been tested and only provides a way for it to be enabled implicitly. We need to investigate and make the changes so that it can be enabled explicitly as well.Currently, the layer has only been tested and only provides a way for it to be enabled implicitly. We need to investigate and make the changes so that it can be enabled explicitly as well.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/5VK_EXT_debug_marker2019-06-05T11:30:55ZBryan Law-SmithVK_EXT_debug_markerCertain tools use the callbacks registered with VK_EXT_debug_marker to profile and/or do frame dumping, so we should support this. This is a good place to track the investigation and any discussions.Certain tools use the callbacks registered with VK_EXT_debug_marker to profile and/or do frame dumping, so we should support this. This is a good place to track the investigation and any discussions.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/3Variable naming conventions are not consistent2019-06-05T13:06:02ZBryan Law-SmithVariable naming conventions are not consistentLooking at the code you can see that certain variables are named with camelCase and others are named with snake_case. This should be changed to be consistent.Looking at the code you can see that certain variables are named with camelCase and others are named with snake_case. This should be changed to be consistent.