The functions that upgraded VkFooMemoryBarrier to VkFooMemoryBarrier2
dropped the pNext pointers. It loses VkSampleLocationsInfoEXT, and may
lose additional structs too if VkFooMemoryBarrier receives further
extensions in the future.
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20477>
The latest includes/registry have some pNext structs that need
guarding spearately to their initial structs, so we have to track
the define guards better and use them in the generated code
For example:
VkVideoEncodeRateControlInfoKHR extends VkVideoCodingControlInfoKHR
However the first struct is protected by BETA, but the second isn't
the generator was always generating unguarded code for all structs
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20384>
The lock and condition variable isn't just for present_id anymore,
it's also for normal forward progress.
Adds more detailed comments what the variables are supposed to
accomplish.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
With the introduction of locks around the XCB polling mechanism,
a possible deadlock was introduced.
If all 5 images were rapidly acquired and presented before the
FIFO thread had the chance to submit a present,
we would deadlock.
Before the lock however, it was still buggy since the two threads would
race to poll events and update internal state.
The fix is to just ensure that there are pending presentation requests
in flight, so that forward progress is guaranteed before we take the
poll lock.
Also, use a timedlock for acquire next image.
Similar as WaitForPresentKHR.
Also need to make the busy flag atomic to actually allow acquire thread
and present threads to access the busy flag.
Take advantage of busy flag being atomic so that we can gracefully handle
timeout == 0 scenarios where there actually are images available.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 8fc7927787 ("wsi/x11: Implement VK_KHR_present_wait on X11.)
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19990>
Drivers implementing descriptor buffers will want to allocate and free
descriptors with the layout for embedded samplers, so we need a hook to
allow them to free any GPU buffers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19849>
Add entrypoints vk_common_CmdDispatch, vk_common_CmdSetDeviceMask,
and vk_common_GetDeviceGroupPeerMemoryFeatures in Mesa Vulkan runtime so
that they are available to all drivers.
Signed-off-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20218>
We set the image type before the extend which allows us to use
vk_image_sanitize_extent.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20112>
When we need to poll the XCB connection with a non-trivial timeout,
be very careful to not hit an XCB bug where a poll() may hang for too
long even if an event is ready in the special event queue.
This is a pragmatic workaround, a wait_for_special_event_with_timeout()
is the only proper solution here.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
There is no pragmatic solution for this.
Comment about the rationale for doing it like this until we have a more
robust solution in XCB.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
If all potentially supported surface types support present wait,
we can expose the extension.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
When vkWaitForPresentKHR succeeds, we are guaranteed
that any dependent semaphores have been unsignalled.
In an explicit sync world, we are guaranteed this automatically by
having a present complete, since that event must follow a semaphore wait
completion.
However, if the swapchain image is implicitly
synchronized, the semaphore might technically not have been unsignaled
before the present complete event triggers.
Present IDs must be signalled in monotonic order, same as timeline
semaphores.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19279>
They are u64. Fixes deadlock in
dEQP-VK.wsi.xcb.present_id_wait.wait.past_no_timeout.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: 9bffd81f1c ("vulkan: Add common implementations of vkQueueSubmit
and vkQueueWaitIdle")
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19951>
wayland-protocols is not a library, it just contains a bunch of
XML files. No need to try to link to it.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19894>
This case was missed in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18826 ,
resulting in native Wayland apps failing with
../src/vulkan/wsi/wsi_common_drm.c:452: wsi_configure_native_image: Assertion `!"Failed to find a supported modifier! This should never " "happen because LINEAR should always be available"' failed.
if the Wayland compositor advertises only the INVALID modifier.
Fixes: c315e20d61 ("vulkan/wsi/wayland: Configure images via params passed to wsi_swapchain_init()")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19795>
Pack the VkSurfaceFormatKHR in here so we can expose formats +
color spaces in one.
This will be needed for exposing HDR color spaces such as
VK_COLOR_SPACE_HDR10_ST2084_EXT.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19726>
The helper used ralloc which is unusual for vulkan objects, did not
handle allocation failures properly and was only useful for RADV.
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19700>
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>
For drivers already using vk_common_ResetCommandBuffer(), it now only
calls the driver's reset hook if the command buffer is not in the
INITIAL state. Pulled this trick from the PowerVR driver.
v2 (Jason Ekstrand):
- Rename from "status" to "state" since that's what's in the spec
- Add vk_command_buffer_begin/end instead of drivers setting it all
manually
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16922>
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>
Function device_select_once_init are removed in-favor of SIMPLE_MTX_INITIALIZER
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18493>
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>
Some drivers need to know the full list of formats that can be used
when VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT or
VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT is set (dozen needs
that at least). While VkImageFormatListCreateInfo is a nice way to
get the actual of formats the user intends to use at view creation time,
this paramter is optional, and when it's missing, we need to know the
full list of compatible formats if we want things to work properly.
Provide a helper that hides all the complexity and return a format list
even when VkImageFormatListCreateInfo is missing.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17339>
In Vulkan, formats are classified in compatible groups, allowing
formats to be cast to other formats in the same group. Some drivers
might need to have access to the full compatible format list, so let's
auto-generate helpers to allow that.
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17339>
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>
