This change adds the tracepoints that can help understand app behavior
for debugging and performance optimization purposes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17497>
Previously we suballocate only for host visible memory type to reduce
the kvm mem slot usage. That is no longer an issue given the limit has
been raised. However, we should still suballocate to make layering
clients performant. So we just suballocate regardless of mem type.
This change also increases the allowed suballocation size request from
64K to 128K, which makes layering clients happier.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17497>
Add support of GUEST_VRAM type of blob. These are dedicated heap memory
allocations required for vk support on hypervisors that don't support
runtime injections of host memory into guest physical address space.
The flow of usage:
1) Host VM reserves dedicated heap memory
2) Device get info about memory reservations and report it to guest
using mmio registers
3) Guest virtio-gpu driver on starts checks mmio registers for
physical address and length of reserved region. Then it reserves it
in guest.
4) On each call of vkAllocateMemory() guest driver gets chunk of
required memory and send it to host using sg list. It uses one sg
entry for 1 blob call. Heap is managed on guest using drm memory
manager (drm_mm).
Signed-off-by: Oleksandr.Gabrylchuk <Oleksandr.Gabrylchuk@opensynergy.com>
Signed-off-by: Andrii Pauk <Andrii.Pauk@opensynergy.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14536>
This change defers the bo allocation for non-external mappable memory
direct allocation.
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/13874>
bo allocations for the below cases are after device memory allocation:
1. direct non-external mappable memory allocation
2. pool grow
3. exportable memory allocation
For (1) and (2), the bo is for mapping, which is a pure kernel operation
to happen later. So roundtrip waiting can be deferred until free memory.
For (3), the bo is for either fd export or mapping, which are both pure
kernel operations. So roundtrip waiting can also be deferred until free
memory.
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/13874>
The behavior we stick to is that the base_bo is always created for pool
memory so that to keep it alive during suballocates and frees.
This CL does the below:
1. rename pool_alloc to pool_suballocate and align the api interface
2. rename simple_alloc to pool_grow_alloc to make it pool specific
3. refactor pool_free and simple_free into a pair of pool_ref and
pool_unref to simplify that vkFreeMemory is only called after the
pool bo gets destroyed.
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/13874>
For blob_mem allocated from virtgpu_virgl backend, the guest mappable
size queried can be smaller than the size returned from image memory
requirement query from the host side. Here we temporarily workaround
until we switch to use cross-domain backend in minigbm.
Cc: 21.2.3 mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12687>
Break it up into vn_{device,instance,physical_device}.h. Suggested by
Ryan Neph.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12144>
When a dedicated allocation is not required, ignore it and suballocate.
Fixes dEQP-VK.api.invariance.random.
Cc: 21.2 mesa-stable
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/12072>
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>
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>
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>
There is no good reason to seprate them. I also plan to adopt
util_sparse_array, which requires the kernel BO to be created first (to
use its gem_handle/res_id as the key).
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/10437>
This commit contains a hack to retrieve extended buffer info, which will
be fixed by moving the logic into gralloc HAL implementation.
With this hack, the rendering result is correct.
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/10259>
This is to ensure the kernel operations and the later ring operations
are in the right order.
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/10390>
VkImportMemoryFdInfoKHR takes fd ownership on a successful import.
Internally, vn_renderer_bo_create_dmabuf doesn't rely on the fd to
extend the life cycle of the bo or the host resource, and it won't
close the fd. Thus, we shall close the fd when the import succeeds.
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/10390>
This change is for supporting VK_ANDROID_native_buffer implementation,
and it does not advertise VK_KHR_external_memory_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/10195>
Move VkDeviceMemory functions to the new files.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10117>
Yiwei Zhang
Oleksandr Gabrylchuk
Chia-I Wu