Using the wl_drm protocol we can check whether the compositor uses the
same GPU as the application.
This allows to run vulkan applications using a DG2 GPU with the
compositor using another card.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19224>
It's not just because we received dma-buf feedback that we should
re-allocate, as sometimes it is useless.
We must compare the most recent allocation parameters used and the ones
that we have with the newest feedback. So do that.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
Follow up of "vulkan/wsi/wayland: add default dma-buf feedback support".
The surface feedback is dynamic, differently from the default feedback.
When we receive per-surface feedback, that means that we could be using
a better DRM format/modifier pair for the chain's buffers. So the next
time that the client calls vkAcquireNextImageKHR(), we return
VK_SUBOPTIMAL_KHR instead of VK_SUCCESS. Some clients will re-create the
swapchain when receiving SUBOPTIMAL, and for those we'll re-create the
chain. An optimal DRM format/modifier pair from the per-surface feedback
will be used to create the images of this swapchain.
Note that for now we won't be able to change the DRM format, only the
modifier. That's good enough for many cases in which direct scanout
would not be possible because of the modifier. In order to be able to
switch the format, we'll need a mechanism to negotiate preferred formats
with clients. Currently we can only expose a set of supported formats
all with the same preference.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
This bumps the supported dma-buf version up to 4 and adds default
dma-buf feedback support. It follows the changes in the dma-buf protocol
extension to include dma-buf feedback.
From version 4 onwards, the dma-buf modifier events are not sent by the
compositor anymore, so we use the default feedback to pick the set of
formats/modifiers supported by the compositor.
In the next commit we add support for per-surface feedback.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
After "vulkan/wsi/wayland: move wl_surface and wl_display from chain to
struct wsi_wl_surface", refcount is being unused. So remove it and its
associated functions.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
When a swapchain is re-created, if the old swapchain is not passed to
us, we need to re-create the wl_display and the Wayland objects. As
described in "vulkan/wsi/wayland: introduce struct wsi_wl_surface", this
gets in the way when adding the dma-buf feedback implementation.
With this change now the lifetime of the Wayland objects is tied to the
VkSurface. When the swapchain gets re-created, we won't have to
re-create the wl_display (and consequently the Wayland objects).
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
When we create a swapchain, take ownership of a struct wsi_wl_surface.
When the chain gets destroyed, the ownership is dropped.
We can safely do that because only a single swapchain can be associated
with the surface at a time, according to vkCreateSwapchainKHR spec:
"If pCreateInfo->oldSwapchain is VK_NULL_HANDLE, and the native
window referred to by pCreateInfo->surface is already associated
with a Vulkan swapchain, VK_ERROR_NATIVE_WINDOW_IN_USE_KHR must
be returned."
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
In the following commits we add dma-buf feedback support. In order to do
that, we need to keep the feedback tied to the lifetime of the surface,
instead of tied to the lifetime of the chain.
Why do we need this change?
The reason is per-surface feedback and swapchain re-creation. If we
receive feedback and return SUBOPTIMAL to the client in the next
acquireNextImage() call, it may re-create the swapchain. If it
doesn't pass us the oldSwapchain, we won't have access to the surface
feedback data (as it was tied to the oldSwapchain). We could bind
again to the surface feedback, but compositors may have a transient
state when we bind to surface feedback, and send a non-optimal batch
of dma-buf feedback which is updated when the drawing loop starts. So
we would re-create the chain with this non-optimal batch, and after a
few moments receive new feedback. This could potentially lead into an
allocation loop, so it is not safe.
Tying the feedback to the lifetime of the VkSurface we don't have to
re-bind to the surface dma-buf feedback every time that the swapchain
is re-created, avoiding this dangerous allocation loop described
above.
So add struct wsi_wl_surface in order to add support for dma-buf
feedback. For now it is just the stub, but in the next commits we start
making use of that.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
We have arbitrary amount of spaces between structs fields types and
their names. That doesn't improve legibility and get in the way when
adding new fields/structs. So remove these spaces.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
There are some structs defined in the middle of the code. Move them
closer to where the other structs are defined.
This makes the code easier to read and also will help us in the next
commits, in which we add dma-buf feedback support.
Reviewed-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12226>
When the Anv pipeline got migrated to the runtime, we gain/lost a bit
of functionality which is that the disk cache is always read
regardless of VK_ENABLE_PIPELINE_CACHE=0.
This change brings the old behavior back.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 591da98779 ("vulkan: Add a common VkPipelineCache implementation")
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19050>
Otherwise users of `idep_vulkan_wsi` won't pull in the udev dependency,
which will cause the linker to fail later on in compiling.
The user of this dependency is lavapipe which would fail to link if this
isn't provided.
Fixes: 4885e63a6d (vulkan/wsi: implement missing wsi_register_device_event)
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19037>
dynamic rasterization samples got added late, and I forgot to update this
Fixes: 1deb83fb86 ("vulkan: Add more dynamic multisample states")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18896>
This should make it a lot more clear how depth clip enables work.
Annoyingly, because of the way they originally worked in Vulkan 1.0,
it's dependent on the depth clamp if the state isn't set in the pipeline
and isn't declared dynamic. The enum is explicitly set up so that
drivers don't need to be aware of this change unless they already
implement VK_EXT_extended_dynamic_state3. If depth clamp/clamp are not
dynamic, depth clip will be either TRUE or FALSE which map to 1/0 so the
field can still be treated as a boolean.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18889>
When the array length is a calculation, the C version of the calculation
is provided in altlen while len often contains LaTeX that we can't do
anything with. Use altlen when available. Also, while we're here, wrap
array lengths in parentheses in case they contain math.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18878>
This flag indicates whether or not the legacy scanout flag is supported.
It defaults to true since that has been the default assumption for the
WSI code up until now.
On NVIDIA hardware, we can't render to linear so, if we don't have
modifiers, we want to automatically fall back to the blit path. In
theory, we could do this inside the driver but it's a giant pain and
much harder to ensure that the blit only happens as part of
vkQueuePresent().
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18826>
VK_DEFINE_NONDISP_HANDLE_CASTS defines two functions.
In some cases only one or the other is used. Marking
them both unused here to avoid warnings.
Fixes a clang warning about unused static inlined functions.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18800>
This is useful for implementing VK_EXT_pipeline_robustness because it
automatically gathers all the bits from everywhere for you.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18690>
Get rid of any zero-sized entries so drivers never even have to think
about this case when using templates.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14780>
We can't actually make the template-based update common efficiently but
we can save everyone a bit of typing by having a common struct. This is
mostly a direct copy+paste from ANV with a type field added and a couple
comments tweaked.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14780>
This was sort of well intentioned, but wrong. bits_per_rgb_value is the
number of significant bits in the color (channel) specification, not the
number of bits used to name that color within the pixel. If you have a
depth 24 visual but the colormap is 11 bits deep then each of those
channels selects one of 256 11-bit color values in the output ramp.
The open source drivers mostly don't expose anything like that, but
nvidia does, and we refuse to work. That's silly. Practically speaking
we can probably render to any TrueColor or DirectColor visual that your
X server exposes, since it is probably not going to have visuals for
non-color-renderable formats. Just check the visual class instead.
Likewise when matching formats to visuals, count the bits in the rgb
masks in the visual.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6995
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18381>
The image is busy until xcb_put_image returns. This isn't a major worry
at the moment since we're doing the PutImage directly from
vkQueuePresent, but if we moved that to a worker thread the race window
would be a lot easier to hit.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18214>
