The initial drm backend implementation for Vulkan passes display device
allocated gbm bos directly to the renderer. This is a bit awkward since
it requires the renderer to maintain a custom output creation interface
and another code path for importing specifically gbm bos.
Since then, vulkan-renderer received support to use dmabuf renderbuffers
to support e.g. pipewire dmabuf, in an interface which is also common
with gl-renderer.
The dmabuf renderbuffer code path is similar to what the drm backend
implementation intended to do, so we can unify it to a single interface.
This has the advantages of requiring one less custom output creation
interface, as well as the renderer being able to handle the drm backend
through a single shared dmabuf renderbuffer path.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
The fbo naming inherited from gl-renderer is confusing, and now it
is used in many places.
Rename the two options for output creation to surface and surfaceless
to hopefully make them more meaningful.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
As spotted in the wild, building without Vulkan still picks up
Vulkan headers. This drops the VkInstance alltogether as that's not
really used.
As this file appears to be pulling XCB headers guard them as well.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
A Vulkan renderer for weston, based on the GL renderer.
The goal is to impose the least requirements as possible on Vulkan
implementations, as to allow even Vulkan 1.0 (or early development)
drivers to run a Wayland compositor. Any additional features or
extensions are made optional if possible.
Currently supports drm, wayland, x11 and headless backends.
As of this implementation, this is still considered an experimental
renderer.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
