On Android, Vulkan loader implements KHR_swapchain and owns both surface
and swapchain handles. On non-Android, common wsi implements the same and
owns the same. So for both cases, the drivers are unable to handle
vkGet/SetPrivateData call on either a surface or a swapchain.
Inspired by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37043
Cc: mesa-stable
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Ryan Zhang <ryan.zhang@nxp.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37064>
This makes it easier to see what all of the assigned values are to check
for collisions, and allows using them in vulkan/util.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37045>
Add a bunch of shortcut names to select physical devices by their device
type.
In particular this aims to make switching between igpu and dgpu easy as
well as testing with lavapipe.
v2:
- rebase and reformat
- use strncasecmp and VkPhysicalDeviceType
- only print debug message when enabled
Signed-off-by: Benjamin Otte <otte@redhat.com>
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com> (v2)
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36717>
In 14b4160792 ("vulkan/wsi: Only test for dma-buf sync file support
once"), I moved the dma-buf sync file import/export check earlier. This
is fine for hardware implementations where we have real dma-buf
import/export but it broke lavapipe because the check itself ignored
whether or not we actually have dma-buf import/export. Add a couple
more checks to wsi_drm_check_dma_buf_sync_file_import_export() so it's
safe even for SW drivers. Also, in wsi_create_sync_for_dma_buf_wait(),
check if we actually have a dma-buf.
Fixes: 14b4160792 ("vulkan/wsi: Only test for dma-buf sync file support once")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37033>
Wine uses vkGetRandROutputDisplayEXT to query some GPU details on start
of a prefix that have to be exposed on the PE side.
Currently this causes minimum of 2 connector reprobes via
DRM_IOCTL_MODE_GETCONNECTOR. This can stall vblanks when timed just
right. In cases where prefixes are started over and over again (e.g.
Steam doing background processing) this causes periodic noticable
stutter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37026>
Strictly speaking, for an empty batch, there is no inherit/defined
ordering between the wait and signal operations within the batch. We
are relying on MESA impl defined behavior to transfer payloads of the
wait sempahores to the signal sempahore here.
Ideally we need a MESA internal hint to ensure transitivity, but since
this is on the legacy fallback path, it's not worth the effort. So here
we follow common wsi to use TRANSFER_BIT which avoids most unnecessary
stalls on the queue (an improvement over the previous ALL_COMMANDS_BIT).
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36855>
This follows common wsi side as suggested, and simplifies the later
adoption of vk_device_copy_semaphore_payloads.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36855>
We're supposed to completely ignore VkTimelineSemaphoreSubmitInfo if
there aren't any timeline semaphores, including the array lengths, which
is made clear by the various VUs already cited by the code. The
vkQueueSubmit() path correctly handled this when asserting but still
dereferenced pWaitSemaphoreValues unconditionally, which could lead to
dereferencing an invalid pointer if waitSemaphoreValueCount is less than
waitSemaphoreCount. The vkQueueSparseBind() path didn't even assert
correctly. Bring vkQueueSparseBind() in line with vkQueueSubmit()
and make both only dereference the wait/signal array once we've
determined it must be present. While we're here, also fix the assert in
vkQueueSubmit() to disallow a waitSemaphoreValueCount of 0 if there are
timeline semaphores present, which conversely is not allowed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36989>
Add it only on external format code path so that no api level guard is
needed. It automatically works with gralloc impls that support
allocating such format.
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36866>
An AHB with IMPLEMENTATION_DEFINED format is commonly backed by NV12 or
XBGR8888. The former is the usual pick for camera <-> GPU interop, while
the latter is mostly only seen in Android CTS. Ideally, we can rely on
the queried fourcc to resolve everything instead of being on the
fallback path, but keeping this a minimal fix is easy for porting.
Cc: mesa-stable
Reviewed-by: Lucas Fryzek <lfryzek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36866>
If we don't need any prime blits then there's no reason to submit
anything to the queue. We can just signal the signal semaphores and
fences with the wait semaphores and skip the queue.
This is only possible because we no longer need a vkQueueSubmit() for
implicit synchronization. The old ANV implicit synchronization path is
gone and all other drivers that do implicit sync do it per-bo so we can
assume that they synchronized somewhere else when writing to the BO and
that the present submit does nothing.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
Vulkan WSI allows you to present to multiple swapchains at the same
time. If it weren't for some of the Vulkan sync rules, this wouldn't be
a big deal as we could just loop and do the present per-swapchain.
However, the whole present takes a single set of wait semaphores and we
can only wait on them once. Right now this works because we do at least
one QueueSubmit2() per-swapchain on the present queue. Since those all
happen on the same queue, we can just wait on the semaphores in the
first present and all the others will pick up that wait thanks to queue
ordering. However, this requires doing a lot of vkQueueSubmit().
This commit changes the vkQueuePresent() flow so that we do a single
vkQueueSubmit2() on the present queue for all swapchains that consumes
the wait semaphores and signals any per-image semaphores and fences. In
the case where separate blit queues are used, we just signal blit
semaphores in the first vkQueueSubmit2() on the present queue and then
do a submit per-swapchain for each of the blit queue blits and signal
per-image semaphores and fences with that submit.
This significantly reduces the number of vkQueueSubmit2() calls being
made by vkQueuePresent() and also breaks the dependency on implicit
ordering of submits, which will be important in the next commit.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
Instead of doing the throttle as we go through the present loop,
allocate throttle fences and wait on them at the top.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
The common entrypoint wrapper already depends on vk_queue, as do all the
drivers that implement drv_QueuePresentKHR() so there's no point in
passing through Vulkan API types anymore.
The one functional change here is that ANV is no longer forcing the
queue index to be zero, which I suspect was a mistake in the first
place.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
This helper existed to ensure that drivers waited for semaphores to
materialize before processing a QueuePresent(). However, most drivers
never called this and they were kind-of fine. Now that we have explicit
and dma-buf sync built into WSI, this wait happens as part
GetSemaphoreFd when we fetch the sync file from the semaphore.
It's also less racy to just rely on GetSemaphoreFd() because, even
though we were stalling the submit thread prior to present, the present
itself does one or more submits and those may go to the thread and
potentially race with the window system. The GetSemaphoreFd(), however,
happens at the right time to ensure we actually stall before handing
off to the window system.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
Venus was the last driver to be implementing old-school vkQueueSubmit()
but it now has a 2-on-1 wrapper as of 07cee75c39 ("venus: layer
vkQueueSubmit2 over vkQueueSubmit w/o sync2"). This makes everything a
little more readable now that we're not juggling separate arrays for
timelines.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
This acts as a vkQueueSubmit() except that it doesn't take any command
buffers or sparse binds and it doesn't act on a queue. Instead, it just
copies semaphore payloads around using a new copy_sync_payloads vfunc on
vk_device.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
This is a trivial case so we don't even need to take the lock.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36827>
The use of the bionic toolchain (DETECT_OS_ANDROID) does not mean
that the typical set of Android libraries (nativewindow, gralloc)
are used on the system.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36829>
As on Windows, all DLLs are exported use def files, there is no need do __declspec(dllexport) on the function marker.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36863>
We can use _mesa_hash_table_init instead of _mesa_hash_table_create.
It doesn't have to be allocated.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
The problem with the current flag is that it seems to belong to
VkShaderCreateFlagsEXT, not VkPipelineShaderStageCreateFlagBits.
Also it is completely skipped by the vk_pipeline.c code.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 7b634ebb63 ("vulkan/runtime: Add VK_SHADER_CREATE_UNALIGNED_DISPATCH_BIT_MESA flag")
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36828>
Instead of each helper having a VK_ERROR_FEATURE_NOT_PRESENT fast-reject
path, drop those paths and check at the top of each caller. This
ensures that we do the check once per wsi_device, and only on a known
test dma-buf and that any subsequent fails turn into fails rather than
silently turning off explicit/implicit sync in potentially inconsistent
ways.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36816>
