From f96e25ae0530be62e8c4b0ca6631643725753190 Mon Sep 17 00:00:00 2001 From: Yiwei Zhang Date: Tue, 12 Jul 2022 06:13:27 +0000 Subject: [PATCH] venus: suballocate more for layering 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 Reviewed-by: Ryan Neph Part-of: --- src/virtio/vulkan/vn_device_memory.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/src/virtio/vulkan/vn_device_memory.c b/src/virtio/vulkan/vn_device_memory.c index 62125cfb2ce..c06c27c7dcf 100644 --- a/src/virtio/vulkan/vn_device_memory.c +++ b/src/virtio/vulkan/vn_device_memory.c @@ -155,10 +155,10 @@ vn_device_memory_pool_suballocate(struct vn_device *dev, uint32_t mem_type_index) { const VkDeviceSize pool_size = 16 * 1024 * 1024; - /* XXX We don't know the alignment requirement. Use 64K because some GPUs - * have 64K pages. It is also required by newer Intel GPUs. But really we - * should require kernel 5.12+, where there is no KVM memslot limit, and - * remove this whole thing. + /* XXX We don't know the alignment requirement. Use 64K because some GPUs + * have 64K pages (e.g. newer Intel ones). Meanwhile, we are not able to + * easily get rid of suballocation because layering clients like angle and + * zink heavily rely on this to be performant on venus. */ const VkDeviceSize pool_align = 64 * 1024; struct vn_device_memory_pool *pool = &dev->memory_pools[mem_type_index]; @@ -193,24 +193,19 @@ vn_device_memory_should_suballocate(const struct vn_device *dev, const VkMemoryAllocateInfo *alloc_info, const VkMemoryPropertyFlags flags) { + /* Native Vulkan apps usually manage suballocation better. However, for + * layering clients like angle or zink, they don't have enough information + * to make wiser choices. Doing suballocation here makes layering more + * performant at this moment. + */ const struct vn_instance *instance = dev->physical_device->instance; const struct vn_renderer_info *renderer = &instance->renderer->info; if (renderer->has_guest_vram) return false; - /* We should not support suballocations because apps can do better. But - * each BO takes up a KVM memslot currently and some CTS tests exhausts - * them. This might not be needed on newer (host) kernels where there are - * many more KVM memslots. - */ - - /* consider host-visible memory only */ - if (!(flags & VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT)) - return false; - - /* reject larger allocations */ - if (alloc_info->allocationSize > 64 * 1024) + /* reject large allocations */ + if (alloc_info->allocationSize > 128 * 1024) return false; /* reject if there is any pnext struct other than