aboutsummaryrefslogtreecommitdiff
path: root/render/vulkan/vulkan.c
AgeCommit message (Collapse)Author
2022-11-24render: stop pulling <wlr/backend.h>Simon Ser
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>.
2022-11-11render/vulkan: remove hardcoded validation layersSimon Zeni
Users should use the VK_INSTANCE_LAYERS env var to set layers at runtime
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-11render/vulkan: add helper to load command function pointerSimon Ser
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().
2022-11-06render/vulkan: use struct initializersSimon Ser
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.
2022-11-06render/vulkan: simplify extension checksSimon Ser
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.
2022-11-04render/vulkan: remove exts arg from vulkan_instance_create()Simon Ser
2022-10-11Fixed false allocation failedGentaiii
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-14render/vulkan: improve format loggingSimon Ser
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.
2022-01-19render/vulkan: log physical device driver nameSimon Ser
This can be useful to figure out why a required feature is missing, e.g. as in [1]. We check VK_EXT_physical_device_drm availability after printing the driver name. [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3358
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>