We don't actually need the REPEAT mode, and this makes things more
consistent with the YCbCr sampler (which requires CLAMP_TO_EDGE for
spec compliance).
Also drop borderColor which is unused for this mode.
Fixes the following validation error:
[ VUID-VkImageViewCreateInfo-pNext-01970 ] Object 0: handle = 0x62e00003c400, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xf378e14b | vkCreateImageView(): If there is a VkSamplerYcbcrConversion, the imageView must be created with the identity swizzle.
Some formats like sub-sampled YCbCr use a block of bytes to
store the color values for more than one pixel. Update our format
table to be able to handle such formats.
This is implemented by a two-subpass rendering scheme; the first
subpass draws (and blends) onto a linear R16G16B16A16_SFLOAT buffer,
while the second subpass performs linear->srgb conversion, writing
onto the actual output buffer.
This fixes the following validation errors when shutting down Sway:
00:00:01.263 [wlr] [render/vulkan/vulkan.c:65] Validation Error: [ VUID-vkDestroyFramebuffer-framebuffer-00892 ] Object 0: handle = 0x62e00003c400, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xdb308312 | Cannot call vkDestroyFramebuffer on VkFramebuffer 0x2e2cd000000002b[] that is currently in use by a command buffer. The Vulkan spec states: All submitted commands that refer to framebuffer must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyFramebuffer-framebuffer-00892) (VUID-vkDestroyFramebuffer-framebuffer-00892)
00:00:01.264 [wlr] [render/vulkan/vulkan.c:65] Validation Error: [ VUID-vkDestroyImage-image-01000 ] Object 0: handle = 0x62e00003c400, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0xf2d29b5a | Cannot call vkDestroyImage on VkImage 0x3fbcd60000000028[] that is currently in use by a command buffer. The Vulkan spec states: All submitted commands that refer to image, either directly or via a VkImageView, must have completed execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkDestroyImage-image-01000) (VUID-vkDestroyImage-image-01000)
Remove debug logs when a texture is created, since this happens
pretty often. Use drmGetFormatName() and drmGetFormatModifierName()
to log DRM formats and modifiers.
This ensures that the pool sizes grow exponentially, making the number
of pools needed logarithmic in the number of descriptors, instead of
linear. Since the first pool's size is 256, this change only has an
effect when the compositor creates a large number of textures.
No need to roll our own cache machinery here, stage buffers
already do it (and more) for us. Should improve performance
when multiple screens with a different resolution are captured.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3525
Let's just forward-declare struct wlr_backend instead.
We need to fixup the Vulkan renderer: it needs makedev(), which
got included by chance via <wlr/backend.h> → <wlr/backend/session.h>
→ <libudev.h>.
Allow to get whether has alpha channel of the VkImage, it can help an
optimization to disable blending when the texture doesn't have alpha.
Because the VkFormat isn't enough because it's always set to
VK_FORMAT_B8G8R8A8_SRGB or VK_FORMAT_R8G8B8A8_SRGB.
It's not safe to destroy any resources which might still be in-use
by the GPU. Wait for any asynchronous tasks to complete before
destroying everything.
Before re-using a VkCommandBuffer, we need to wait for its
operations to complete. Right now we unconditionally wait for
rendering to complete in vulkan_end(), however we have plans to
fix this [1]. To fully avoid blocking, we need to handle multiple
command buffers in flight at the same time (e.g. for multi-output,
or for rendering followed by texture uploads).
Implement a pool of command buffers. When we need to render, we
pick a command buffer from the pool which has completed its
operations. If we don't find one, try to allocate a new command
buffer. If we don't have slots in the pool anymore, block like we
did before.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3574
Up until now we were using a VkFence for GPU-to-CPU
synchronization. This has some limitations that become a blocker
when trying to have multiple command buffers in flight at once
(e.g. for multi-output). It's desirable to implement a command
buffer pool [1], but VkFence cannot be used to track command buffer
completion for individual subpasses.
Let's just switch to timeline semaphores [2], which fix this issue,
make synchronization a lot more ergonomic and are a core Vulkan 1.2
feature.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3802
[2]: https://www.khronos.org/blog/vulkan-timeline-semaphores
If NULL is returned by vkGetDeviceProcAddr(), either the driver
is buggy, either the wlroots code is buggy. For a valid device and
command name, drivers are not allowed to return NULL per the spec.
This mirrors what the GLES2 renderer does in load_gl_proc().
Added wlr_vk_renderer_get_* functions to allow get the VkInstance,
VkPhysicalDevice, VkDevice, queue family of a wlr_vk_renderer.
Added wlr_vk_renderer_get_current_image_attribs function to allow get
the VkImage of current renderer buffer to use on compositors.
Added wlr_renderer_is_vk function, it's like the wlr_renderer_is_gles2,
returns true if the wlr_renderer is a wlr_vk_renderer.
Added wlr_vk_image_get_attribs function to get a VkImage and it's
extras information (e.g. a VkImageLayout and VkImageFormat of the
VkImage) from a wlr_texture.
Instead of filling the fields one by one, use a struct initializer.
This avoids repeating the name of the variable and is more
consistent with the wlroots code style.
find_extensions() is clunky to use when checking only a single
extension, and it's surprising that it returns NULL on success.
Simplify by replacing it with a check_extension() function which
just checks whether a single extension is in the list.
