From: Niklas Haas <ffmpeg@haasn.xyz> To: ffmpeg-devel@ffmpeg.org Cc: Niklas Haas <git@haasn.dev> Subject: [FFmpeg-devel] [PATCH] avutil/hwcontext_vulkan: disable host transfers if ReBAR is disabled Date: Fri, 20 Jun 2025 14:43:20 +0200 Message-ID: <20250620124320.43327-1-ffmpeg@haasn.xyz> (raw) From: Niklas Haas <git@haasn.dev> This feature fundamentally relies on host-visible VRAM, which restricts the set of available memory types to (typically) host-visible device-local ones. When resizable BAR is disabled, this memory type is usually limited to e.g. 256 MiB in size, which is just plain insufficient for allocation of general purpose GPU images, causing OOM errors on even the simplest of commands. The easiest solution is to disable host transfers entirely on machines without host-addressable VRAM. In theory, we could try and recover the use of host transfers for images which are *not* restricted to device-local memory types, but this is rarely the case in practice, and the effort required would exceed the benefit, especially since ReBAR is a standard feature on all platforms recent enough to have Vulkan drivers, and only occasionally disabled in the UEFI for by default for some hare-brained notion of "backwards compatibiility" with ancient software. --- libavutil/hwcontext_vulkan.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index edff89af26..b0a765e370 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -144,6 +144,9 @@ typedef struct VulkanDevicePriv { /* Disable multiplane images */ int disable_multiplane; + /* Disable host image transfer */ + int disable_host_transfer; + /* Maximum queues */ int limit_queues; @@ -1694,6 +1697,23 @@ static int vulkan_device_create_internal(AVHWDeviceContext *ctx, goto end; } + /* Get device memory properties */ + vk->GetPhysicalDeviceMemoryProperties(hwctx->phys_dev, &p->mprops); + VkDeviceSize max_vram = 0, max_visible_vram = 0; + for (int i = 0; i < p->mprops.memoryTypeCount; i++) { + const VkMemoryType type = p->mprops.memoryTypes[i]; + const VkMemoryHeap heap = p->mprops.memoryHeaps[type.heapIndex]; + if (!(type.propertyFlags & VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT)) + continue; + max_vram = FFMAX(max_vram, heap.size); + if (type.propertyFlags & VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT) + max_visible_vram = FFMAX(max_visible_vram, heap.size); + } + + /* Only use host image transfers if ReBAR is enabled */ + const int has_rebar = max_vram - max_visible_vram < 1024; /* 1 kB tolerance */ + p->disable_host_transfer = !has_rebar; + /* Get all supported features for the physical device */ device_features_init(ctx, &supported_feats); vk->GetPhysicalDeviceFeatures2(hwctx->phys_dev, &supported_feats.device); @@ -1990,9 +2010,6 @@ FF_ENABLE_DEPRECATION_WARNINGS if (!hwctx->unlock_queue) hwctx->unlock_queue = unlock_queue; - /* Get device capabilities */ - vk->GetPhysicalDeviceMemoryProperties(hwctx->phys_dev, &p->mprops); - p->vkctx.device = ctx; p->vkctx.hwctx = hwctx; @@ -2835,7 +2852,7 @@ static int vulkan_frames_init(AVHWFramesContext *hwfc) VK_IMAGE_USAGE_STORAGE_BIT | VK_IMAGE_USAGE_SAMPLED_BIT); - if (p->vkctx.extensions & FF_VK_EXT_HOST_IMAGE_COPY) + if ((p->vkctx.extensions & FF_VK_EXT_HOST_IMAGE_COPY) && !p->disable_host_transfer) hwctx->usage |= supported_usage & VK_IMAGE_USAGE_HOST_TRANSFER_BIT_EXT; /* Enables encoding of images, if supported by format and extensions */ -- 2.49.0 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next reply other threads:[~2025-06-20 12:43 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-06-20 12:43 Niklas Haas [this message] 2025-06-20 16:30 ` Lynne
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20250620124320.43327-1-ffmpeg@haasn.xyz \ --to=ffmpeg@haasn.xyz \ --cc=ffmpeg-devel@ffmpeg.org \ --cc=git@haasn.dev \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git