This takes a different approach. It turns out we can patch
vkCmd{Begin,End}RenderPass, vkCmdWaitEvents, and vkCmdPipelineBarrier to
do queue family ownership transfers without tracking image ownerships.
v2: check the value of VN_PRESENT_SRC_INTERNAL_LAYOUT and keep this
Android-only
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10709>
Add vn_cmd_{wait_events,pipeline_barrier}_fix_image_memory_barries to
replace vn_get_intercepted_barriers. The two new functions are
identical currently, but that will change soon.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10709>
We need them for wsi queue ownership transfer.
v2: make VN_PRESENT_SRC_INTERNAL_LAYOUT public
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10709>
If the state was set to VN_COMMAND_BUFFER_STATE_INVALID, return
VK_ERROR_OUT_OF_HOST_MEMORY in vn_EndCommandBuffer.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10709>
dEQP-VK.api.external.memory.opaque_fd.* re-imports and fails because
external_handles was VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT on
allocation and is VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT on
re-import.
Fixes: ccefcb0baf ("venus: fix misaligned bo_flags between import and query")
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11154>
Always chain wsi_image_create_info to VkImageCreateInfo, which indicates
that the image is a wsi image and can be transitioned to/from
VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
Add prime_blit_buffer to the struct as well. When set, it indicates the
prime blit destination and implies that the image is a prime blit
source.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10789>
Spec requires apps to use the size returned from
vkGetAndroidHardwareBufferPropertiesANDROID for AHB import, which
includes dedicated image/buffer import and non-dedicated buffer import.
Spec requires venus to use the size from image and buffer memory
requirement for dma_buf fd import if it's dedicated. If not dedicated,
the actual payload size should be used.
For AHB export allocation of VkImage, the app provided size will be 0,
and internally we must use the size from image memory requirement.
For AHB export allocation of VkBuffer, the app provided size comes from
buffer memory requirements and it can be smaller than the actual AHB
size due to page alignment. Internally that's the size we must use.
For AHB import, app must use the size from AHB prop query. Internally,
we have to override that with the size from memory requirement if the
import operation is dedicated to a VkImage or a VkBuffer. If not
dedicated, the actual payload size should be used.
The not working scenario is:
1. App creates an AHB backed VkBuffer, and the exported AHB size is
larger than the buffer memory requirement (very common).
2. App imports the AHB without a dedicated VkBuffer. Then the entire
AHB payload will be imported and the mmap_size might increase.
Test: dEQP-VK.api.external.memory.android_hardware_buffer.*
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11055>
For importing an dma_buf fd, export info is not required. Leaving the
bo_flags missing VIRTGPU_BLOB_FLAG_USE_SHAREABLE bit as well as the
VIRTGPU_BLOB_FLAG_USE_CROSS_DEVICE bit. Upon querying fd properties,
DMA_BUF handle type will be specified which generates a new bo_flags
not matching the prior one.
This patch aligns the above 2 bits for the dma_buf import path.
Test: vkGetAndroidHardwareBufferPropertiesANDROID should succeed with
a valid AHB with AHARDWAREBUFFER_FORMAT_BLOB format.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11055>
Besides advertising AHB support, for Android, we do not advertise
KHR_external_memory_fd, EXT_external_memory_dma_buf or
EXT_image_drm_format_modifier so that AHB remains the sole channel for
external resource sharing.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10960>
This patch refactors the struct look up logic for memory allocation, and
it prepares the necessary info for ahb allocation and import.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10960>
This patch wraps up fd import logic, which will be used later by ahb
import. This patch also removes a redundant check in need_bo.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10960>
1. bail early if there's no compatiable AHB format
2. check against the corresponding drm format modifier
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10960>
This is to pass the Android cts requirement. We will re-advertise the
extension after venus has a valid driver id defined.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10819>
Some apps such as Gamescope crash under the mere presence of the virtio Vulkan driver without using a device.
This is because virtgpu::fd is zero-initialized upon allocation, which causes fd 0 to be closed in virtgpu_destroy.
Cc: mesa-stable
Fixes: 247232d5 ("venus: add experimental renderers")
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10814>
