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>
Some drivers such as lavapipe are 100% fine with using linear for WSI
images. Most HW drivers, however, would rather render tiled and eat a
blit.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
This isn't a big deal for the current buffer paths because the required
alignment for PRIME is already higher than any driver advertises.
However, the SW path we're about to add won't have the PRIME requirement.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
Instead of taking a single boolean for device-local, take a set of
required properties and denied properties. This will let us require
additional things like being CPU mappable in the future.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17388>
