aboutsummaryrefslogtreecommitdiff
path: root/include/render/vulkan.h
AgeCommit message (Collapse)Author
2022-11-15render/vulkan: add wlr_vk_texture_has_alphazccrs
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.
2022-11-11render/vulkan: always wait for last stage to complete before renderingSimon Ser
When we have multiple command buffers in flight, we need to make sure we don't start rendering before the previous texture uploads are complete.
2022-11-11render/vulkan: use command buffer pool for stageSimon Ser
2022-11-11render/vulkan: add a command buffer poolSimon Ser
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
2022-11-11render/vulkan: switch to timeline semaphoresSimon Ser
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
2022-11-07render/vulkan: use wl_array for wlr_vk_shared_buffer.allocsSimon Ser
Avoids the need to open-code the realloc() logic.
2022-11-07render/vulkan: fix and add missing wl_list commentsSimon Ser
In wlroots we add comments near struct wl_list members to indicate which type it's linked to. The Vulkan renderer had some comments with mistakes, and some members without a comment.
2022-11-04render/vulkan: drop outdated commentsSimon Ser
2022-11-04render/vulkan: remove exts arg from vulkan_instance_create()Simon Ser
2022-11-04render/vulkan: add caching to vulkan_read_pixelsDavid96
2022-10-10render/vulkan: drop wlr_vk_instance.extensionsSimon Ser
This was unused. Even if it was, it'd be better to have bool fields instead.
2022-09-30render/vulkan: use addon for wlr_vk_textureSimon Ser
Avoids having to walk the list of all textures.
2022-09-30render/vulkan: use addon for wlr_vk_render_bufferSimon Ser
Avoids having to walk the list containing all of the render buffers.
2022-09-07render/vulkan: drop wlr_vk_device.extensionsSimon Ser
We don't need to store the list of enabled extensions. While at it, rename variables to be less confusing.
2022-09-07render/vulkan: drop ext params from vulkan_device_create()Simon Ser
These are unused.
2021-11-17Remove support for DMA-BUF flagsSimon Ser
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.
2021-10-18render/vulkan: add Vulkan renderernyorain
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>