aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_vulkan.c
Commit message (Collapse)AuthorAgeFilesLines
...
* hwcontext_vulkan: do not require libdrm to map VAAPI devicesLynne2023-05-291-5/+8
| | | | VAAPI is sadly on the way of becoming multiplaform.
* hwcontext_vulkan: add support for descriptor buffersLynne2023-05-291-1/+12
|
* hwcontext_vulkan: report nonCoherentAtomSizeLynne2023-05-291-0/+2
|
* hwcontext_vulkan: fix minor type issue in VulkanQueueCtx.buf_deps_alloc_sizeLynne2023-05-291-1/+1
|
* hwcontext_vulkan: rename and expand vk_pixfmt_map to append VK_NULL_FORMATLynne2023-05-291-5/+5
|
* hwcontext_vulkan: remove contiguous memory path/modeLynne2023-05-291-12/+0
| | | | | | | | | | | | | | | | | The hack was added to enable exporting of vulkan images to DRM. On Intel hardware, specifically for DRM images, all planes must be allocated next to each other, due to hardware limitation, so the hack used a single large allocation and suballocated all planes from it. By natively supporting multiplane images, the driver is what decides the layout, so exporting just works. It's a hack because it conflicted heavily with image allocation, and with the whole ecosystem in general, before multiplane images were supported, which just made it redundant. This is also the commit which broke the hwcontext hardest and prompted the entire rewrite in the first place.
* hwcontext_vulkan: support threadsafe queue and frame operationsLynne2023-05-291-48/+143
|
* hwcontext_vulkan: use portability subset if availableLynne2023-05-291-1/+3
|
* hwcontext_vulkan: enable VK_KHR_synchronization2 if supportedLynne2023-05-291-4/+12
|
* hwcontext_vulkan: enable support for YCbCr samplersLynne2023-05-291-0/+1
|
* hwcontext_vulkan: initialize and require instance version 1.3Lynne2023-05-291-1/+1
| | | | | | | | | | | | This just bumps the required loader library version (libvulkan). All device-related features, such as video decoding, atomics, etc. are still optional and the code deals with their loss on a local level (e.g. the decoder or filter checks for the features it needs, not the hwcontext). Bumping the required version essentially packs all maintenance extensions which correct the spec rather than requiring to enable them individually.
* lavu/vulkan: fix handle type for 32-bit targetsKacper Michajłow2023-03-071-1/+1
| | | | | | | Fixes compilation with clang which errors out on Wint-conversion. Signed-off-by: Kacper Michajłow <kasper93@gmail.com> Signed-off-by: Martin Storsjö <martin@martin.st>
* vulkan: Fix win/i386 calling conventionMartin Storsjö2023-03-071-4/+4
| | | | | | | | | | | This fixes the following error when compiling with a modern version of Clang for Windows/i386: src/libavutil/hwcontext_vulkan.c:738:32: error: incompatible function pointer types initializing 'PFN_vkDebugUtilsMessengerCallbackEXT' (aka 'unsigned int (*)(enum VkDebugUtilsMessageSeverityFlagBitsEXT, unsigned int, const struct VkDebugUtilsMessengerCallbackDataEXT *, void *) __attribute__((stdcall))') with an expression of type 'VkBool32 (VkDebugUtilsMessageSeverityFlagBitsEXT, VkDebugUtilsMessageTypeFlagsEXT, const VkDebugUtilsMessengerCallbackDataEXT *, void *)' (aka 'unsigned int (enum VkDebugUtilsMessageSeverityFlagBitsEXT, unsigned int, const struct VkDebugUtilsMessengerCallbackDataEXT *, void *)') [-Wincompatible-function-pointer-types] .pfnUserCallback = vk_dbg_callback, ^~~~~~~~~~~~~~~ Signed-off-by: Martin Storsjö <martin@martin.st>
* hwcontext_vulkan: remove optional encode/decode extensions from the listLynne2022-12-251-8/+0
| | | | | | | They're not currently used, so they don't need to be there. Vulkan stabilized the decode extensions less than a week ago, and their name prefixes were changed from EXT to KHR. It's a bit too soon to be depending on it, so rather than bumping, just remove these for now.
* lavu/hwcontext_vulkan: support mapping VUYX, P012, and XV36Philip Langdale2022-09-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | If we want to be able to map between VAAPI and Vulkan (to do Vulkan filtering), we need to have matching formats on each side. The mappings here are not exact. In the same way that P010 is still mapped to full 16 bit formats, P012 has to be mapped that way as well. Similarly, VUYX has to be mapped to an alpha-equipped format, and XV36 has to be mapped to a fully 16bit alpha-equipped format. While Vulkan seems to fundamentally lack formats with an undefined, but physically present, alpha channel, it has have 10X6 and 12X4 formats that you could imagine using for P010, P012 and XV36, but these formats don't support the STORAGE usage flag. Today, hwcontext_vulkan requires all formats to be storable because it wants to be able to use them to create writable images. Until that changes, which might happen, we have to restrict the set of formats we use. Finally, when mapping a Vulkan image back to vaapi, I observed that the VK_FORMAT_R16G16B16A16_UNORM format we have to use for XV36 going to Vulkan is mapped to Y416 when going to vaapi (which makes sense as it's the exact matching format) so I had to add an entry for it even though we don't use it directly.
* avutil/hwcontext_vulkan: fix typo in undefZhao Zhili2022-03-141-1/+1
|
* hwcontext_vulkan: use VkPhysicalDeviceTimelineSemaphoreFeaturesZhao Zhili2022-02-011-1/+11
| | | | | | | VkPhysicalDeviceVulkan12Features isn't implemented on MoltenVK yet. VkPhysicalDeviceTimelineSemaphoreFeatures is less versatile but simple. None of device_features_1_1 nor device_features_1_2 has real usage yet, keep the code for future.
* lavu/hwcontext_vulkan: clear dangling pointers on map failureAnton Khirnov2022-01-211-0/+1
|
* avutil/hwcontext_vulkan: fixed incorrect memory offsetWu Jianhua2022-01-051-5/+7
| | | | | | | | This commit fixed hwupload in Vulkan: ffmpeg -init_hw_device vulkan -i test.jpg -vf hwupload,hwdownload,format=yuv420p -y out.jpg Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
* hwcontext_vulkan: remove VK_EXT_hdr_metadata from autoloaded extensions listLynne2022-01-031-1/+0
| | | | | | We don't use it. Was copied from libplacebo's recommended defaults. Creates problems with validation on Intel devices, where the driver still advertizes it, even though it's not usable without a swapchain.
* hwcontext_vulkan: wait on semaphores when exporting to DRMLynne2021-12-101-0/+11
| | | | There is no synchronization method for DRM yet.
* hwcontext_vulkan: support creating DRM-tiled images and autodetecting modifiersWenbin Chen2021-12-101-8/+155
| | | | | | | | | | | | | | | When vulkan image exports to drm, the tilling need to be VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT. Now add code to create vulkan image using this format. Now the following command line works: ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format \ vaapi -i input_1080p.264 -vf "hwmap=derive_device=vulkan,format=vulkan, \ scale_vulkan=1920:1080,hwmap=derive_device=vaapi,format=vaapi" -c:v h264_vaapi output.264 Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Further-modifications-by: Lynne <dev@lynne.ee>
* hwcontext_vulkan: add support for mapping frames with planes in a single ↵Wenbin Chen2021-12-101-2/+9
| | | | | | | | | | VkDeviceMemory Add support to map vulkan frames to software frames when using contiguous_planes flag. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Further-modifications-by: Lynne <dev@lynne.ee>
* hwcontext_vulkan: add support for allocating all planes in a single allocationWenbin Chen2021-12-101-2/+74
| | | | | | | | | | | | | | VAAPI on Intel can import external frame, but the planes of the external frames should be in the same drm object. A new option "contiguous_planes" is added to device. This flag tells device to allocate places in one memory. When device is derived from vaapi this flag will be enabled. A new flag frame_flag is also added to AVVulkanFramesContext. User can use this flag to force enable or disable this behaviour. A new variable "offset "is added to AVVKFrame. It describe describe the offset from the memory currently bound to the VkImage. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Further-modifications-by: Lynne <dev@lynne.ee>
* hwcontext_vulkan: use correct return value for allocation failureLynne2021-11-271-1/+1
|
* avutil/hwcontext_vulkan: fully support customizable validation layersWu Jianhua2021-11-261-29/+135
| | | | | | | | | | Validation layer is an indispensable part of developing on Vulkan. The following commands is on how to enable validation layers: ffmpeg -init_hw_device vulkan=0,debug=1,validation_layers=VK_LAYER_LUNARG_monitor+VK_LAYER_LUNARG_api_dump Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
* avutil/hwcontext_vulkan: check if created before destroying the instanceWu Jianhua2021-11-241-1/+2
| | | | Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
* avutil/hwcontext_vulkan: check if created before destroying the deviceWu Jianhua2021-11-241-1/+2
| | | | Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
* hwcontext_vulkan: check for non-flagged transfer queue familiesLynne2021-11-201-0/+7
| | | | | | | | | "All commands that are allowed on a queue that supports transfer operations are also allowed on a queue that supports either graphics or compute operations. Thus, if the capabilities of a queue family include VK_QUEUE_GRAPHICS_BIT or VK_QUEUE_COMPUTE_BIT, then reporting the VK_QUEUE_TRANSFER_BIT capability separately for that queue family is optional."
* lavu/vulkan: move common Vulkan code from libavfilter to libavutilLynne2021-11-191-7/+3
|
* avutil/hwcontext_vulkan: add support for exporting memory via Win32 HandlesTimo Rothenpieler2021-11-141-6/+96
|
* hwcontext_vaapi: don't use the generic mapping struct for DRM/VAAPILynne2021-11-131-19/+11
| | | | Avoids a per-frame allocation since we don't need the flag field.
* hwcontext_vulkan: fix small memory leak when unmappingLynne2021-11-131-0/+1
|
* hwcontext_vulkan: wait for semaphores when unmapping from VAAPILynne2021-11-131-0/+10
| | | | | We don't really want to do a full all-queue blocking wait here, since this happens once per frame, and this could delay future frames.
* hwcontext_vulkan: print error information on queue submission failureLynne2021-11-131-0/+2
| | | | Makes it clearer what went wrong.
* hwcontext_vulkan: fix DMABUF import format check callLynne2021-11-131-0/+4
| | | | | VkExternalImageFormatProperties is required to be present in the .pNext chain of VkImageFormatProperties2, or some drivers crash (RADV).
* hwcontext_vulkan: improve CUDA error handlingLynne2021-11-131-12/+14
|
* hwcontext_vulkan: close exported memory FD on CUDA import errorLynne2021-11-131-0/+1
| | | | Prevents resource leakage.
* hwcontext_vulkan: do not dup() semaphore FDs for CUDALynne2021-11-131-5/+1
|
* hwcontext_vulkan: properly migrate queue families with DRM import/exportLynne2021-11-131-11/+1
|
* hwcontext_vulkan: properly migrate between queue families on CUDA import/exportLynne2021-11-131-41/+52
| | | | It's more correct.
* hwcontext_vulkan: properly error out if timeline semaphores are unsupportedLynne2021-11-131-0/+1
| | | | Missing goto.
* hwcontext_vulkan: fix CreateSemaphore conflict with synchapi.hLynne2021-11-121-6/+7
| | | | | | Include windows.h to fix it. Normally, it'd be better to include it in vulkan_functions.h, but I'm reasonably confident nothing else that uses the Vulkan code will need to include Windows functions and not windows.h.
* hwcontext_vulkan: use vkDeviceWaitIdle instead of vkWaitSemaphores on uninitLynne2021-11-121-9/+3
| | | | | To silence a possible validation layer bug, switch the function. It only gets triggered by vf_libplacebo, which is odd.
* lavu: move hwcontext_vulkan's function loader into separate filesLynne2021-11-121-226/+67
| | | | This allows for the loader to be shared with libavcodec and libavfilter.
* hwcontext_vulkan: clean up extensions code and add additional defaultsLynne2021-11-121-8/+18
|
* hwcontext_vulkan: host wait on semaphores before freeing frameLynne2021-11-121-0/+11
|
* hwcontext_vulkan: report device that's usedLynne2021-11-121-1/+6
| | | | Not sure why this wasn't done before.
* vulkan: add support for encode and decode queues and refactor queue codeLynne2021-11-121-117/+181
| | | | | | | | | This simplifies and makes queue family picking simpler and more robust. The requirements on the device context are relaxed. They made no sense in the first place. The video encode/decode extension is still in beta, at least on paper, but I really doubt they'd change needing a separate queue family.
* hwcontext_vulkan: port CUDA interop to use timeline semaphoresLynne2021-11-121-3/+25
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-08 22:59:19 +0000