aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_vulkan.c
Commit message (Collapse)AuthorAgeFilesLines
* all: fix typos found by codespellTimo Rothenpieler22 hours1-1/+1
|
* hwcontext_vulkan: transfer exclusive images to correct queue family in ↵vytskalt2 days1-1/+1
| | | | drm->vulkan mapping
* hwcontext_vulkan: fix issues with importing a deviceLynne2025-06-271-7/+9
| | | | | The previous fix just used a local variable for the memory properties, which did not fix this issue.
* hwcontext_vulkan: fix 85c0364b703Lynne2025-06-241-0/+3
| | | | | The issue is that by moving the mprops loading later, we inadvertently broke some earlier dependencies.
* hwcontext_vulkan: add workaround for broken Nvidia driversLynne2025-06-241-0/+6
|
* hwcontext_vulkan: move ReBAR check into a new function and use it laterLynne2025-06-241-17/+26
| | | | | | | | The issue is that vulkan_device_create_internal() is only called for devices that lavu creates by itself. For external devices, this was never done. This also solves some mid-function declaration warnings.
* avutil/hwcontext_vulkan: disable host transfers if ReBAR is disabledNiklas Haas2025-06-221-4/+21
| | | | | | | | | | | | | | | | | | | 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.
* vulkan: maintain compatibility with old headersLynne2025-06-171-13/+13
| | | | Previous patch to fix these issues was incomplete.
* vulkan: maintain compatibility with older headersLynne2025-06-121-2/+2
|
* hwcontext_vulkan: fix image copyLynne2025-06-111-14/+25
| | | | | The patch was applied by mistake in an unfinished form. This fixes the build and lets the code run.
* hwcontext_vulkan: use host image copyLynne2025-06-111-2/+121
|
* hwcontext_vulkan: add a setting to limit queuesLynne2025-06-101-2/+15
| | | | | If its a problem, you'll likely want to set it to 1 than more fine-grained control, which you can already do via the API.
* hwcontext_vulkan: minimize queue allocation on NVIDIALynne2025-06-101-1/+19
| | | | | | | | | | | | On NVIDIA, there's a global maximum limit of approximately 112 queues, which means it takes ONLY 7 total programs using the maximum amount of queues to cause the driver to error out/*segfault* during initialization. Also, each queue takes about 30ms to allocate, which quickly adds up. This reduces the queues allocate to the minimum that we would be happy with. Its not worth limiting decode/encode queues as they're generally not a lot, and do help.
* hwcontext_vulkan: do not use optical flow queueus by defaultLynne2025-06-101-8/+0
| | | | | We don't use them, and on NVIDIA, each queue takes around 30ms to allocate, and the driver has a global limit of ONLY 112 queues.
* avutil/vulkan: add YUVA pixel formats supportNiklas Haas2025-05-281-0/+17
| | | | | Signed-off-by: Niklas Haas <git@haasn.dev> Sponsored-by: nxtedition
* hwcontext_vulkan: fix build with old Vulkan header versionsLynne2025-05-211-1/+1
|
* hwcontext_vulkan: only try exporting DMABUF memory on !WIN32 and only for ↵Lynne2025-05-201-2/+3
| | | | DMABUF tiling
* hwcontext_vulkan: correct image transfer usage flagsLynne2025-05-201-2/+2
| | | | | By pure coincidence, BUFFER and IMAGE flags were equal for those two usage types.
* vulkan: enable VK_KHR_shader_subgroup_rotateLynne2025-05-201-0/+5
| | | | Yet another thing that should've been always present.
* avutil/hwcontext_vulkan: Query the correct formatLink Mauve2025-05-071-1/+1
| | | | | | | | | | In the call to vkGetPhysicalDeviceImageFormatProperties2(), we were previously requesting the properties of the first fallback format (e.g. VK_FORMAT_R8_UNORM for VK_FORMAT_G8_B8R8_2PLANE_420_UNORM) instead of the actual format in use. We don’t do anything with it afterwards, but there is no reason to keep querying the wrong format.
* hwcontext_vulkan: support AV_PIX_FMT_GBRPLynne2025-05-011-0/+1
| | | | | Support was partially added previously in vulkan.c, but now it's fully supported.
* hwcontext_vulkan: enable subgroupSizeControlLynne2025-04-221-0/+1
| | | | | | | We already use this feature for setting the subgroup size, but this feature was not enabled. Fixes a validation warning.
* vulkan: move OPT_CHAIN out of hwcontext_vulkanLynne2025-04-221-36/+27
| | | | | | This allows for it to be shared. Technically, implementations should not give drivers structs that the drivers are not familiar with.
* vulkan: move feature<->usage mapping code outside of hwcontext_vulkan.cLynne2025-04-221-36/+6
| | | | | Allows for it to be reused. In particular, for a future patch to make vulkan hwaccels output DMABUF-backed VkImages.
* vulkan: use a single command buffer per command buffer poolLynne2025-04-161-1/+0
| | | | | | | | | | We violated the spec, which, despite the actual command buffer pool *not* being involved in any functions which require external synchronization of the pool, *require* external synchronization even if only the command buffers are used. This also has the effect of *significantly* speeding up execution in case command buffers are contended.
* avutil/hwcontext_vulkan: use the typedef'd name for the expect_assume structJames Almer2025-04-151-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/hwcontext_vulkan: check if expect_assume is supported by the headerJames Almer2025-04-151-0/+9
| | | | | Reviewed-by: Lynne <dev@lynne.ee> Signed-off-by: James Almer <jamrial@gmail.com>
* vulkan: add support for expect/assumeLynne2025-04-141-0/+7
| | | | | | This commit adds support for compiler hints. While on AMD these are not used/needed, Nvidia benefits from them, and gives a sizeable 10% speedup on 4k.
* hwcontext_vulkan: disable descriptor buffer extension on IntelLynne2025-04-141-1/+21
| | | | | Temporary workaround. Will be replaced with a version check once a fix is in the works and a known next version for Mesa with a fix is known.
* avutil/hwcontext_vulkan: Remove unused variableAndreas Rheinhardt2025-04-031-1/+0
| | | | | | Forgotten in 8c7b00ba3ac4b55d6e48f9a5a4345bbf19c9cb2e. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* avutil/hwcontext_vulkan: stop checking for deprecated and removed flagllyyr2025-03-291-3/+0
| | | | | | | | AV_VK_FRAME_FLAG_CONTIGUOUS_MEMORY was deprecated in e0f2d2e70228d022195afccc057bd6dc8b688c21 and removed in 09a57602991d47011247f2683f32a53255adcf09 Fixes: e0f2d2e70228d022195afccc057bd6dc8b688c21 Fixes: 09a57602991d47011247f2683f32a53255adcf09
* vulkan: add support for AV_PIX_FMT_GBRAP32Lynne2025-03-171-0/+1
|
* hwcontext_vulkan: enable VK_KHR_video_maintenance2Lynne2025-03-171-0/+13
| | | | Enables some fixes for the video specifications, and a new feature.
* hwcontext_vulkan: allow using concurrent access images with more than 5 queuesLynne2025-03-171-1/+1
| | | | | | This limit was not bumped when the queue family rewrite happened. Fixes validation issues on nvidia.
* hwcontext_vulkan: fix downloads; use the common host map function to map ↵Lynne2025-03-171-160/+77
| | | | | | | | | | frame data This commit uses the recently exported code for host mapping images back where it was exported from. The function also had broken download code for image downloading since its recent refactor.
* hwcontext_vulkan: add support for mapping multiplane images into CUDALynne2025-03-111-102/+160
| | | | | | | | | | | | | This patch refactors the CUDA import code to allow for Vulkan images with multiple planes to be mapped. Currently, a driver bug exists which causes NV12 images to be mapped incorrectly when the memory being mapped contains both planes, the issue has been reported to NVIDIA. yuv420p does work correctly, however. This is still an improvement, as the code used to crash when trying to map the memory, unless disable_multiplane=1 was given as an option.
* vulkan: add support for AV_PIX_FMT_GRAY32Lynne2025-03-011-0/+1
|
* hwcontext_vulkan: enable read/write without storageLynne2025-02-271-0/+2
| | | | | | | | | | BGR formats in Vulkan cannot be used in storage images, as the pixel labels on storage images are always ordered as RGB, and swizzling is not an option due to old hardware limitations. This means that you must always use an RGB format and manually swizzle when reading or writing to BGR images, or simply not use a format in the shader itself. This adds support for the latter.
* vulkan: don't query video queue properties unless the extension is enabledLynne2025-02-211-2/+2
| | | | Fixes validation errors.
* hwcontext_vulkan: check if semaphores are exportable before enabling exportingLynne2025-01-131-17/+40
| | | | | | | | | lavapipe recently added support for external_semaphore_fd, but only for syncfiles, not for opaque file descriptors. The code is written to allow using syncfiles later on. Ref: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12422
* hwcontext_vulkan: add VK_EXT_layer_settings to optional instance extensionsLynne2025-01-031-0/+1
| | | | | | | | The issue is that some compilers complain if a struct or array is empty. This extension does nothing by default, and can be useful, so just add it to keep the array non-empty.
* configure: add option to statically link to libvulkanLynne2024-12-231-0/+9
| | | | | | | This may be useful in weird setups and on platforms where static linking to libvulkan is supported. libplacebo also has this fallback.
* vulkan: do not reinvent a queue context structLynne2024-12-231-10/+10
| | | | | | | | | | We recently introduced a public field which was a superset of the queue context we used to have. Switch to using it entirely. This also allows us to get rid of the NIH function which was valid only for video queues.
* hwcontext_vulkan: disable validation layer threading warningsLynne2024-12-231-0/+1
| | | | | The layer is buggy currently: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/9045
* hwcontext_vulkan: do not enable portability subset by defaultLynne2024-12-231-0/+2
| | | | | It doesn't make sense to, and could result in the implementation picking emulation layers.
* hwcontext_vulkan: take disable_multiplane into account when checking for formatsLynne2024-11-261-2/+2
|
* hwcontext_vulkan: require storage properties to claim formats as supportedLynne2024-11-261-2/+2
| | | | | | | | | | | This function dates back a long time ago, before vkfmt_from_pixfmt2. When it was converted over, the thought was that this was far too restrictive to demand storage images for each format. With the new clever function, it makes sure to check that the compatible subformats a format can be used as support storage capabilities. This gets rid of fake support for RGB48/RGB96 which some implementations offer but don't support using as storage images.
* hwcontext_vulkan: add support for AV_PIX_FMT_GBRAP10/12/14Lynne2024-11-261-0/+3
|
* hwcontext_vulkan: add support for AV_PIX_FMT_GBRP12/14/16Lynne2024-11-261-2/+7
|
* hwcontext_vulkan: add support for AV_PIX_FMT_GRAY10/12/14Lynne2024-11-261-0/+3
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 09:49:30 +0000