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.
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.
We were checking whether any of the features was supported. We need
to check if all of them are.
This makes the check consistent with query_modifier_support() above.
From a comment by emersion:
> There is a logic error here: we pass 0xFFFFFFFF to vulkan_find_mem_type, which
> returns an index, and then we logical-and that with mem_reqs.memoryTypeBits.
> Instead we should pass mem_reqs.memoryTypeBits to vulkan_find_mem_type and use
> the result for the memoryTypeIndex field directly. Ideally checking for errors
> (-1 return value) in case no memory type is suitable.
Closes: #3470
This lets the renderer handle the wlr_buffer directly, just like it
does in texture_from_buffer. This also allows the renderer to batch
the rectangle updates, and update more than the damage region if
desirable (e.g. too many rects), so can be more efficient.
Whether a texture is opaque or not doesn't depend on the renderer
at all, it just depends on the source buffer. Instead of forcing
all renderers to implement wlr_texture_impl.is_opaque, let's move
this in common code and use the wlr_buffer format to know whether
a texture will be opaque.
`vulkan_format_props_query` calls `query_modifier_support` which
initializes fields of `props` with allocated memory. this memory is
leaked if `query_modifier_support` does not find a supported format
and shmtex is not supported, as in this case `add_fmt_props` ends
up being false and the allocated fields of `props` are never freed.
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
zccrs
Simon Zeni
David96
Gentaiii
John Lindgren
Bernardo Meurer
bi4k8
nyorain
Joshua Ashton