Rename macro HAVE_PIPE_LOADER_DRI to HAVE_DRI
Rename macro HAVE_PIPE_LOADER_KMS to HAVE_DRISW_KMS
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17784>
Now that we have a common pipeline layout with reference counting, we
don't need these driver hooks for reference counting anymore.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17286>
handleTypes is allowed to be null with VK_STRUCTURE_TYPE_EXPORT_MEMORY_ALLOCATE_INFO
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Closes#6501
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16590>
to allow exposing 4G - 1. The "SIZE" was also a misnomer because it meant
elements. This no longer clamps the size to INT_MAX in st/mesa.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16881>
gallium can't directly support vertex attribute instance rate zero, since
the instance rate is also used to determine if the data is per-vertex or
per-instance in the first place (hence divisor zero meaning the data is
per vertex).
While it's an optional feature for VK_EXT_vertex_attribute_divisor, some
apps require it to work (it's a standard d3d10 feature and widely
supported), hence translate it away as MAX_UINT32 divisor instead (which
at this point probably makes more sense than to change the gallium
interface), which should work all the same.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16526>
When lvp_queue_init fails, propagate the failure to the caller.
Signed-off-by: Greg Depoire--Ferrer <greg.depoire@gmail.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15071>
this avoids races in llvmpipe related to modification of per-context shader
variant lists, which causes massive amounts of flakiness in ci
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16331>
This helper has built-in support to be quieted, which seems like a good
idea to do on ci.
Let's enable the quieting while we're at it.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16033>
When porting lavapipe to the common sync framework, I stole the dummy
sync signal_for_memory idea from RADV but didn't actually do it
correctly. Unless you set wsi_device::signal_semaphore_with_memory and
wsi_device::signal_fence_with_memory, it doesn't actually signal
anything. If you do set those, it works but also results in dummy
syncs being created for present fences which we see as signals. We
could choose to just skip those like RADV does but that's too magic.
Instead, have our own AcquireNextImage2() again which sets dummy syncs.
Fixes: 3b547a9b58 ("lavapipe: Switch to the common sync framework")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15774>
The common Vulkan sync framework will do most of the queueing for us.
It will even sort out timeline semaphore dependencies and ensure
everything executes in-order. All we have to do is make sure our
vk_sync type implements VK_SYNC_FEATURE_WAIT_PENDING. This lets us get
rid of a big pile of code.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15651>
it's not random, but it's definitely not zero or any other expected
value, which means it's going to break anything that was passing due to lucky
uninitialized values
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15620>
maybe just being overly paranoid, but make sure that the timeline id
gets compared while the lock is held in every scenario
cc: mesa-stable
Reviewed-by: Omar Akkila <omar.akkila@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15453>
the vulkan spec doesn't explicitly state whether this function progresses
a given semaphore's timeline, and apparently there are some cases where
it's assumed that progress occurs if this function is called in a loop
instead of WaitSemaphores, so check the current fence for completion
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15453>
MSVC doesn't support typeof(). If we want to keep compiling radv on
windows we need to use the typed variants of those macros.
Fixes: dc8fdab71e ("lavapipe: Use VK_OUTARRAY for GetPhysicalDeviceQueueFamilyProperties[2]")
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15518>
this converts the existing code to use VkSubmitInfo2 structs and adds
a new QueueSubmit wrapper which generates these structs from VkSubmitInfo
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15413>