AHardwareBuffer_Format is lossier than DRM_FORMAT_*, which ends up with
unable to resolve implementation defined format upon creating sampler
ycbcr conversion. So we now use DRM format as AHB external format.
An external format error return in vkCreateSamplerYcbcrConversion is
also removed here since that is already an invalid usage per spec
(partly because there is no proper error code to return here).
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/11480>
CrOS gralloc was missing support for GPU_DATA_BUFFER, which was only
fixed until recently. Now we can allcate properly.
This patch also removes a redundant TODO regarding image format list
support for AHB. vkGetPhysicalDeviceImageFormatProperties2 has already
checked the support for such though it only checks whether the optimal
tiling and the associated drm format modifier for the AHB image format
itself applies to the entire format list or not. Given the use case for
such combination is quite limited, we choose not to add new gralloc
support to force linear modifier as a fallback for wider coverage.
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/11501>
This patch refactors to use vn_Import*FdKHR for Android WSI native sync
fence import when globalFencing is supported. Currently there's no perf
win from this, but will move the composer release fence waiting to the
GPU device side automatically when the entire Venus fencing support is
improved.
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/11342>
It is simpler. But I mainly want to work around
../src/virtio/vulkan/vn_cs.h:173:4: error: argument 1 null where non-null expected [-Werror=nonnull]
173 | memcpy(val, dec->cur, val_size);
We trust virglrenderer and it never instructs the decoder to memcpy to
pData when it is NULL. The compiler does not know however. A proper
fix will be to generate
if (!pData)
unreachable();
to help the compiler.
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/11174>
Upon instance creation, venus experimental features are cached in the
vn_instance. If memoryResourceAllocationSize feature is supported, chain
VkMemoryResourceAllocationSizeProperties100000MESA to the pNext of
VkMemoryResourcePropertiesMESA to get the host allocation size of the
dma_buf fd.
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/11048>
We introduce vkGetVenusExperimentalFeatureData100000MESA to negotiate
experimental venus features under development between the guest and the
host, which can help avoid breaking existing clients of venus. All the
experimental features will be cleaned up and merged into core upon
finalizing venus protocol.
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/11048>
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>
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>
Yiwei Zhang