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)
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.
The Vulkan spec doesn't guarantee that the driver will wait for
implicitly synchronized client buffers before texturing from them.
radv happens to perform the wait, but anv doesn't.
Fix this by extracting implicit fences from DMA-BUFs, importing
them into Vulkan as a VkSemaphore objects, and make the render pass
wait on these VkSemaphores.
pre_cb was an alias for stage_cb->vk. Let's just use a single
variable instead.
Additionally, early return when vulkan_record_stage_cb() fails.
We were crashing in vkCmdPipelineBarrier() if that happened.
Skip clears with an empty scissor.
Fixes the following validation error:
00:00:09.734 [wlr] [render/vulkan/vulkan.c:61] Validation Error: [ VUID-vkCmdClearAttachments-rect-02682 ] Object 0: handle = 0x62600001b100, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xadbd476f | CmdClearAttachments(): pRects[0].rect.extent.width is zero. The Vulkan spec states: The rect member of each element of pRects must have an extent.width greater than 0 (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkCmdClearAttachments-rect-02682) (VUID-vkCmdClearAttachments-rect-02682)
We were filling VkTimelineSemaphoreSubmitInfoKHR.pSignalSemaphoreValues,
but we were missing VkSubmitInfo.pSignalSemaphores.
This was causing VkTimelineSemaphoreSubmitInfoKHR.pSignalSemaphoreValues
to be ignored. By chance, the render command buffer was using the
next timeline point, so we were waiting for that instead.
Right now the Vulkan renderer blocks until the frame is complete
after rendering. This is necessary because Vulkan doesn't
interoperate well with implicit sync we use everywhere else.
Use the new kernel API to import a sync_file into a DMA-BUF to
avoid blocking.
We need to wait for the pending command buffer to complete before
re-using stage buffers. Otherwise we'll overwrite the stage buffer
with new contents before the texture is fully uploaded.
We need to wait for any pending command buffer to complete before
we're able to fully destroy a struct wlr_vk_texture: the Vulkan
spec requires the VkDescriptorSet to be kept alive.
So far we've done this in vulkan_end(), after blocking until the
command buffer completes. We'll soon stop blocking, so move this
logic in get_command_buffer(), where we check which commands buffers
have completed in a non-blocking fashion.
vkCmdCopyBufferToImage requires that the buffer offset be a multiple
of the texel block size, which for single plane uncompressed formats
is the same as the number of bytes per pixel. This commit adds an
alignment parameter to vulkan_get_stage_span which ensures that the
provided span (and the sequence of image copy operations derived which
use it) have this alignment.
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
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.
They are never used in practice, which makes all of our flag
handling effectively dead code. Also, APIs such as KMS don't
provide a good way to deal with the flags. Let's just fail the
DMA-BUF import when clients provide flags.
This new renderer is implemented with the existing wlr_renderer API
(which is known to be sub-optimal for some operations). It's not
used by default, but users can opt-in by setting WLR_RENDERER=vulkan.
The renderer depends on VK_EXT_image_drm_format_modifier and
VK_EXT_physical_device_drm.
Co-authored-by: Simon Ser <contact@emersion.fr>
Co-authored-by: Jan Beich <jbeich@FreeBSD.org>
Simon Ser
Manuel Stoeckl
Jan Beich
Brett Ernst
llyyr
Simon Zeni
zccrs
David96
John Lindgren
nyorain
Joshua Ashton