vulkan-wsi-layer issueshttps://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues2023-10-27T07:42:14Zhttps://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/24Question about WSI_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN2023-10-27T07:42:14Zxuelian baiQuestion about WSI_IMAGE_COMPRESSION_CONTROL_SWAPCHAINHi, in https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/blob/main/CMakeLists.txt?ref_type=heads#L207, `BUILD_WSI_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN` is enabled when compling, but I met a issue, that, `VK_EXT_image_compression_cont...Hi, in https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/blob/main/CMakeLists.txt?ref_type=heads#L207, `BUILD_WSI_IMAGE_COMPRESSION_CONTROL_SWAPCHAIN` is enabled when compling, but I met a issue, that, `VK_EXT_image_compression_control_swapchain` is enabled in wsi, but ICD don't support this extension, then TC failed, I'm wondering why not check if this extension is enabled when runtime, instead of adding in json when compiling.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/20The Vulkan loader may disable the Vulkan WSI Layer depending on apiVersion2022-09-09T10:00:26ZMatteo FranchinThe Vulkan loader may disable the Vulkan WSI Layer depending on apiVersionWhen calling `vkCreateInstance`, an application can provide the `VkInstanceCreateInfo::pApplicationInfo::apiVersion` field, defined as the highest Vulkan version the application is designed to use, see https://www.khronos.org/registry/vu...When calling `vkCreateInstance`, an application can provide the `VkInstanceCreateInfo::pApplicationInfo::apiVersion` field, defined as the highest Vulkan version the application is designed to use, see https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkApplicationInfo.html. This is not necessarily the API version that the application will end up using. In particular, the application may end up using an earlier Vulkan API version if there are no Installable Client Drivers (ICDs) in the system that support the newer version.
At the same time, the Vulkan specification demands that: “Implicit layers must be disabled if they do not support a version at least as high as `apiVersion`” and the Khronos Vulkan loader implements this recommendation. Unfortunately, this recommendation is problematic for implicit layers that implement one or more Vulkan extensions. It means that an implementation of a Vulkan extension provided as an implicit layer can stop working for applications that advertise ability to use newer Vulkan APIs. The problem would not occur if the extension was implemented in the ICD, instead.
This problem can be worked around by updating the Vulkan WSI Layer so that it supports the latest Vulkan API at all times. However, this approach may not be practical in certain cases. For example, in cases where a device stops receiving updates but still allows its user to access applications from an online store, which is continuously updated.
Another possible workaround is changing the Vulkan Loader to never disable the Vulkan WSI Layer. It is then the system integrator’s responsibility to ensure the Vulkan runtime is consistent, i.e. the Vulkan WSI Layer supported API version is not lower than the API version supported by all the other components in the Vulkan runtime (loader, ICDS, other layers.)
A solution to this problem is currently being investigated.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/17Testing / example code2023-07-17T08:56:40ZAnton BTesting / example codeHey. Thanks for your work. Any chance that you have some example code that really works (able to render anything) with headless surface?
First I tried to modify famous vkcube app to use vkCreateHeadlessSurfaceEXT(). Surface creation seem...Hey. Thanks for your work. Any chance that you have some example code that really works (able to render anything) with headless surface?
First I tried to modify famous vkcube app to use vkCreateHeadlessSurfaceEXT(). Surface creation seems to pass (function returns without any error and the pointer is filled with some address), but than the app crashes in
`demo->fpGetPhysicalDeviceSurfaceSupportKHR(demo->gpu, i, demo->surface, &supportsPresent[i]);`
If I replace this line with
`supportsPresent[i] = 1;`
it than crashes in
`demo->fpGetPhysicalDeviceSurfaceFormatsKHR(demo->gpu, demo->surface, &formatCount, surfFormats);`
etc.
I am very new to Vulkan (just about 4 hours) and I suspect that I am doing something wrong. But I've also tried to compile that SaschaWillems' (not that I like his style) repository with -DUSE_HEADLESS and everything there crashes too.
In case you care, my goal is to make vulkan apps run on X11/wayland servers that don't support DRI and can only use shared memory. We currently have more or less working vulkan driver (called turnip) for adreno GPUs that can work even with proprietary kernels on Android devices, but existing Android X11/wayland solutions don't support DRI. So I hoped that I can hook some functions, force all vulkan apps to render to some offscreen buffer, than download image and send it to X11 window through shared memory. I already did so a long time ago using libhybris.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/16Use wl_display_roundtrip_queue() function instead of open-coding it2021-04-12T11:03:33ZIason ParaskevopoulosUse wl_display_roundtrip_queue() function instead of open-coding itSee [comment](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250523).See [comment](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250523).https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/15Use wl_proxy wrapper to prevent race conditions2021-04-15T16:34:12ZIason ParaskevopoulosUse wl_proxy wrapper to prevent race conditionsSee comments [1](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250524) and [2](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250529).See comments [1](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250524) and [2](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250529).https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/14Use the Linux dmabuf extension to query the supported formats in Wayland wsi2021-03-31T09:24:03ZIason ParaskevopoulosUse the Linux dmabuf extension to query the supported formats in Wayland wsiUse the Linux dmabuf extension (zwp_linux_dmabuf_v1) to query the supported formats in the surface_properties::get_surface_formats() function in Wayland wsi.Use the Linux dmabuf extension (zwp_linux_dmabuf_v1) to query the supported formats in the surface_properties::get_surface_formats() function in Wayland wsi.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/13Add support for multiple images on Wayland swapchain images2021-04-23T08:59:44ZIason ParaskevopoulosAdd support for multiple images on Wayland swapchain imagesSee [comment](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250522).See [comment](https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/merge_requests/2#note_250522).https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/12Investigate the use of FIFO present mode on Wayland.2021-04-22T17:25:17ZIason ParaskevopoulosInvestigate the use of FIFO present mode on Wayland.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/11vkCreateHeadlessSurfaceEXT entry point missing?2020-04-29T16:28:33ZLionel LandwerlinvkCreateHeadlessSurfaceEXT entry point missing?The `README.md` file claims that the project implements VK_EXT_headless_surface, but I can't find the `vkCreateHeadlessSurfaceEXT` entry point anywhere.
Maybe I misunderstanding how this work, but I would expect this entry point to be ...The `README.md` file claims that the project implements VK_EXT_headless_surface, but I can't find the `vkCreateHeadlessSurfaceEXT` entry point anywhere.
Maybe I misunderstanding how this work, but I would expect this entry point to be implemented by the layer.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/10Set up continuous integration2019-10-02T15:24:35ZMatteo FranchinSet up continuous integrationWe should set up continuous integration for the Vulkan WSI Layer. At the very least we should add a job that builds the layer as a sanity check. We should then expand this to check that the code runs properly. Initially we may want to ru...We should set up continuous integration for the Vulkan WSI Layer. At the very least we should add a job that builds the layer as a sanity check. We should then expand this to check that the code runs properly. Initially we may want to run a simple test. We can then use this as a base and add more and more tests as we go along with the development of the project.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/9Choice of programming language2020-01-24T13:12:51ZDavid Harvey-MacaulayChoice of programming languageCurrently the project is written using a subset of C++. We should reconsider whether this is a good choice given the size of the project and the complexity C++ introduces.
For consistency with other freedesktop.org projects and simplici...Currently the project is written using a subset of C++. We should reconsider whether this is a good choice given the size of the project and the complexity C++ introduces.
For consistency with other freedesktop.org projects and simplicity of implementation, perhaps we should consider writing in C instead.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/7Layer should ignore (pass through) calls for surface types it does not support2021-11-30T15:49:51ZBryan Law-SmithLayer should ignore (pass through) calls for surface types it does not supportCurrently in the layer, for VK_KHR_surface queries, the layer will always return information for the surface type it currently understands (headless). What it should do is pass through such calls to the ICD in case the ICD supports that ...Currently in the layer, for VK_KHR_surface queries, the layer will always return information for the surface type it currently understands (headless). What it should do is pass through such calls to the ICD in case the ICD supports that surface type.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/4Add Wayland support2021-11-30T15:51:47ZBryan Law-SmithAdd Wayland supportRight now the layer only has support for the headless surface extension. It would add much utility to the driver if it also supported a windowing system such as Wayland. This is a good place to have that discussion and track the work.Right now the layer only has support for the headless surface extension. It would add much utility to the driver if it also supported a windowing system such as Wayland. This is a good place to have that discussion and track the work.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/2Investigate Vulkan 1.1 requirements (VK_KHR_device_group)2021-10-28T15:04:18ZBryan Law-SmithInvestigate Vulkan 1.1 requirements (VK_KHR_device_group)The layer implements the VK_KHR_swapchain extension, however on Vulkan 1.1 that extension is also responsible for functionality introduced in the VK_KHR_device_group extension as well, and this needs to be taken into account.
Namely, th...The layer implements the VK_KHR_swapchain extension, however on Vulkan 1.1 that extension is also responsible for functionality introduced in the VK_KHR_device_group extension as well, and this needs to be taken into account.
Namely, there is now the ability to create a VkImage that will be be bound in such a way to be essentially an alias for one of a swapchain's images. This is done through extension structures to VkImageCreateInfo (VkImageSwapchainCreateInfoKHR) and VkBindImageMemoryInfo (VkBindImageMemorySwapchainInfoKHR).
Some thought and investigation needs to go into how to architect this.https://gitlab.freedesktop.org/mesa/vulkan-wsi-layer/-/issues/1Remove the use of std::mutex2020-04-29T16:37:19ZBryan Law-SmithRemove the use of std::mutexLooking through the code, you can see that the layer uses both std::mutex and pthread_mutex_t to do synchronization. This shouldn't be happening, especially since we're trying to avoid the use of exception throwing C++ objects.
We shou...Looking through the code, you can see that the layer uses both std::mutex and pthread_mutex_t to do synchronization. This shouldn't be happening, especially since we're trying to avoid the use of exception throwing C++ objects.
We should remove the std::mutex usage, replacing it with pthreads.
Additionally, there's no explicit reference to libpthread in the CMakeLists.txt, so that should be updated as well.