After using sparse array to manager virtgpu bo, we set gem_handle to 0
to indicate that the bo is invalid. However, the gem handle gets closed
before that and can be reused by another newly created bo, leading to
the tracked gem handle being unexpectedly zero'ed out.
Fixes: 88f481dd74 ("venus: make sure gem_handle and vn_renderer_bo are 1:1")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30362>
Skip dEQP-VK.binding_model.mutable_descriptor.multiple_arrays_mixed.*
because lavapipe behind venus can end up returning OODM for device
memory allocations.
The instability likely started from lavapipe gaining support of dma-buf
import/export. Then vkr renderer would no longer use the opaque fd
export with lavapipe, and we are hitting certain bottleneck of udmabuf.
Let's get venus ci re-enabled now and we can later flip vkr back to
prefer opaque fd export if seeing lavapipe for comparison.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Daniel Stone <daniel.stone@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30356>
Fix to call vn_image_bind_wsi_memory as long as the image is a wsi
image. This is needed so that we track the wsi memory in the wsi image
so that creating from swapchain info works normally on x11/wayland
platforms. This change also make it clear that ANB image owns the wsi
memory
Fixes: c4b30b604f ("venus: support VK_ANDROID_NATIVE_BUFFER_SPEC_VERSION 8")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30278>
Venus implements guest WSI on host external memory and thus cannot
transition guest wsi images to/from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
Thus, when a client would attempt to transition a Venus wsi image
to/from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR, Venus instead transitions
to/from VK_IMAGE_LAYOUT_GENERAL and performs an explicit ownership
transfer to/from VK_QUEUE_FAMILY_FOREIGN_EXT. Unfortunately, the
read-only guarantee of VK_IMAGE_LAYOUT_PRESENT_SRC_KHR is lost.
Upon the "acquire from foreign queue" side of that symmetry, when a
client would attempt to retain the contents of the image (i.e.
transition from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR instead of
VK_IMAGE_LAYOUT_UNDEFINED), Venus knows that the image's backing memory
has not been modified. Thus, when those "acquire from FOREIGN queue"
ownership transfers flow to the native driver, Venus can signal it to
skip any acquisition-time validation of an image's internal data,
obtaining the same optimization as native WSI.
This is useful for drivers such as ARM's Mali (with Transaction
Elimination) that would otherwise need to recompute costly per-tile
checksums (CRCs) to ensure that they haven't gone stale during FOREIGN
ownership of the image's memory.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
Image memory barriers don't need to be fixed when Venus' internal
"presentable" layout is PRESENT_SRC (generally only in specific types of
debugging). In that case, skip barrier fixes as early as possible and
remove early returns from procedures deeper in the call stack.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
Prepare to allocate VkExternalMemoryAcquireUnmodifiedEXT structs from
command pool cached storage with the same lifetime as
VkImageMemoryBarrier(2) structs.
Also use common parameter naming and function call signatures for the
both the barrier and barrier2 variants.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
If ring is already current when creating bo, we skip the ring wait but
miss to invalidate bo ring seqno. There's a false-positive for sending a
ring wait upon free memory if the ring has consumed about UINT32_MAX
bytes of traffic (unrelated to ring size).
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29988>
The aliased WSI image creation path is very much like the AHB case. It's
also the same with the deferred ANB binding path to support
VK_EXT_swapchain_maintenance1. Drop the cap as mesa currently only
supports up to spec version 8 because the later versions haven't been
upstreamed to the Vulkan registry yet.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29864>
This exists due to historical limitations which have long gone obsolete.
This persists longer due to hostorical perf issues that have recently
gone obsolete on the platforms shipping Venus. Meanwhile, clients like
skiavk and ANGLE nowadays do a better job managing suballocations. The
tiny perf win from having this giant internal pool has been beaten by
the memory waste, longer one-shot jank due to largier alloc, allocations
no need to be mapped but only because host-visible is advertised across
mem types and varies workarounds and markups needed to make alignment
work and make VVL happy. Dropping it also reduces the maintenance cost.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29362>
The contents were previously copied with vk_copy_struct_guts(),
now that we use vk_set_physical_device_properties_struct, the sType
is needed.
Fixes: ("3c152a6e5dd venus: Use common physical device properties")
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29314>
This lets us delegate the GPDP2 entrypoint to common code.
This also lets us delete struct vn_physical_device_properties,
as it is redundant with struct vk_properties present in the runtime.
Move the properties present in vn_physical_device_properties to the
local_devices struct used to query the host device properties, so we can
still get and fill those properties.
Replace accesses to struct vn_physical_device with accesses to
struct vk_properties filled in at device initialization time.
v2: rebase and a few fixups (zzyiwei)
- rely solely on vk props for final props sanitizations
- set vk11 props behind vk 1.2 condition
- set default pci props if forwarded
- set extension props based on extension support
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Reviewed-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
