This needs to extend the VkMemoryRequirements2 struct, not
VkImageMemoryRequirementsInfo2.
Fixes: ad0f4cf9 ("vulkan-renderer: make dmabuf import dedicated allocation optional")
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Add a debug binding and mode to highlight (green tint) what has
been rendered through vulkan-renderer composition. This is useful
to visually identify/debug clients which have been offloaded to
DRM planes, since those won't go through the renderer composition
process and therefore won't be highlighted the same way.
Since this is the first debug mode in vulkan-renderer, add some
initial infrastructure to handle debug bindings.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
In order to be more in line with weston_view_is_opaque() - which we
use in most cases to set the value - and ensure the expectations of
existing places in the code are honored, see usages in both
draw_paint_node() implementations.
An exception here are holes - these always need to get painted as fully
opaque in the renderer path.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
It's the same as buffer->direct_display essentially 100% of the time,
except maybe if someone set weston_direct on a single-pixel-buffer, but
that's madness.
Just drop it entirely, and let the only existing reader of the variable
get it from the buffer directly.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
This is not strictly always necessary depending on the implementation,
so the extension requirement can be made optional.
Also improve its usage by first checking whether the dedicated
allocation is preferred/required by the driver, before importing
with dedicated allocation.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Writeback connectors often support multiple formats, fully independent
of the input framebuffer. Wire up support for querying formats and send
them to clients.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
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>
Remove the limited shm formats hardcoded list and add a query to
populate them according to the device.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Define extension tables for all extensions that are potentially used,
and use that to enumerate and request extensions which will be used.
This allows for a bitset to hold supported extensions and makes it
less cumbersome to define new ones to use later, as well as requiring
less traversing of the extension string list to decide which extensions
to request.
This also fixes some missing dependency issues which could trigger
validation errors on some drivers with limited extension support.
It also allows some code paths that didn't require some specific
extensions that were in the default list before, by checking for
those in the code path that actually uses them at runtime.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Let's be more more specific and rename the renderer interface function
that returns the supported dma-buf formats. I.e. if we pass a dma-buf
with one of these formats for the renderer, it should be able to import
it.
Next we'll introduce a function to query the rendering formats from
the renderer, so this distinction is important.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Initial support for dmabuf renderbuffers, based on the GL renderer
implementation.
This enables Vulkan renderer to use the pipewire backend with dmabuf.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Rework the dmabuf import Vulkan code so that it is possible to reuse
a single routine across the DRM backend gbm import and dmabuf client
import.
This is will also make it possible to reuse it for dmabuf renderbuffers
as a follow-up.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Decouple render_fence_fd from the DRM output, in particular so that
it is allowed in headless outputs (for upcoming dmabuf renderbuffers).
Also simplify the code to make it clear that it is handled per-output.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
For swapchain outputs, in some cases it is possible that a frame becomes
available by its fence but the last used swapchain image has still not
been returned to the swapchain. If the render_done semaphore is part of
the frame struct it will be reused and cause a validation error.
To prevent this from happening, move the render_done semaphore to the
image struct so that each of those semaphores is only used when the
associated image is safely acquired from the swapchain.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
The captured buffer cannot be just memcpy'ed to the destination as
it might overwrite existing pixels outside of the capture region.
For now switch it to a pixman composition.
Signed-off-by: Erico Nunes <nunes.erico@gmail.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>
