Fixes the following UBSan error:
../src/vulkan/wsi/wsi_common_wayland.c:654:27: runtime error: load of misaligned address 0x6110000666b4 for type 'dev_t' (aka 'unsigned long'), which requires 8 byte alignment
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19595>
If an application was transitioning out of fullscreen exclusive
display mode, the wsi_display_connector->active state was not
reset in vkReleaseDisplay() from fullscreen. When the app then
later tried to go to fullscreen display mode again on the same
display output with the same video mode, this caused
_wsi_display_queue_next() to skip a required drmModeSetCrtc()
during the first vkQueuePresent() after entering direct display
mode.
While this often worked by pure luck on a single-display setup,
it goes sideways on a multi-display setup where the viewport
of the associated crtc does not have a (x,y) offset of (0,0).
E.g., XOrg/X11 RandR output leasing of an output whose viewport
starts at x = 1920:
1. X-Server has RandR outputs viewport at x = 1920, in a shared
framebuffer, shared across all crtc's on a X-Screen.
2. Application leases that output for direct display mode,
1st vkQueuePresent() triggers drmModeSetCrtc() of output
to (x,y) = 0,0, as required for Vulkan/wsi/direct framebuffer
setup.
3. Application does rendering and presenting.
4. Application vkReleaseDisplay() the output, terminates the
RandR lease. X-Server takes over again.
5. X-Server modesets to reconfigure output back to viewport
with (x,y) = 1920, 0.
6. Application leases same output again later on, and tries
vkQueuePresent() again. Because of the bug fixed in this
commit, the required drmModeSetCrtc() to (x,y) = 0,0 is
erroneously skipped due to the stale cached connector state.
7. drmModePageflip() fails due to the wrong crtc viewport
(x,y) = 1920, 0, mismatched for the need of the Vulkan
framebuffer of (x,y) = 0,0. Kernel returns -ENOSPACE,
Swapchain goes into permanent VK_ERROR_SURFACE_LOST state.
Destroying and recreating the swapchain, as recommended
by the Vulkan spec for error handling won't help. Game over!
Resetting wsi_display_connector->active = false; fixes the
problem of wrong / stale connector state and Vulkan/wsi/display
clients are happy on multi-display setups again, as tested
in various single- and multi-display configurations.
This bug affects all Mesa releases with Vulkan/WSI/Display
support and should therefore be backported.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Fixes: 352d320a07 ("vulkan: Add EXT_direct_mode_display [v2]")
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19484>
If the surface is already in use by another swapchain, return
VK_ERROR_NATIVE_WINDOW_IN_USE_KHR. The spec states:
> 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.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
References: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7467
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19229>
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>
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>
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>
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>
For AMD we kinda have some modifiers with a max size ... (Which is
really a compositor/kms issue, but getting them to try kinda falls
into the unsolved "how to allocate/what pitch to use" bucket, so
we solve it on the allocating side)
Cc: mesa-stable
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18139>
Yes this is a round trip, but X_PresentPixmap is not itself a blocking
operation, it just instructs the server to do the next presentation at
some time. More importantly, if _we_ don't catch the presentation error,
xlib's error queue will, and the calling code is certainly not prepared
to handle errors from Present.
Forcing the round trip here is also a bit more correct semantically.
This is the end of the Vulkan client part of the present queue, and the
X_PresentPixmap request transfers the queue operation to the server, so
we should not return until we are sure the handoff has happened.
Fixes some flakiness with piglit@glx-visuals-* with zink+radv.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17685>
in this case, lying about having multiple images and then returning the
same image every time doesn't work, so use the busy flag
and return an available image when possible
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17590>
We're about to make it so that the compiler warns/errors if you use the
wrong iterator macro. Fix up a bunch of places where someone used the
wrong one before we break anything.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17630>
First, because we're using __vk_append_struct which attacks it on the
end, memory_wsi_info is modified even though it's const. Make things
non-const so we aren't silently violating assumptions. Also, we set a
pNext in memory_export_info which causes a loop in the pNext chain in
the handle_types != 0 case.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6826
Fixes: 124848bf9e ("vulkan/wsi: Support tiled CPU images")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17434>
