We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
Reverts commit c73e20628a.
This caused a regression in the GLES2 renderer because `egl->exts.EXT_device_drm` is set in
`egl_init_display()`, which is invoked after `get_egl_device_from_drm_fd()`. So the function will
always return `EGL_NO_DEVICE_EXT`.
Some formats like YUV are only supported by Mesa for sampling, not
for rendering. However we always unconditionally added the INVALID
modifier to the list of render formats.
Check whether all modifiers are external-only, in that case, don't
add INVALID to the list of render formats.
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.
struct wlr_vk_format_props contains a mix of properties for shm
and dmabuf, and it's not immediately clear which fields are for
which kind of buffer. Use a nested struct to group the fields.
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.
