aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_vulkan.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* hwcontext_vulkan: fix mapping from/to DRM/VAAPI framesLynne2021-11-121-84/+121
|
* hwcontext_vulkan: switch to using timeline semaphoresLynne2021-11-121-10/+81
|
* hwcontext_vulkan: bump required Vulkan loader version to 1.2Lynne2021-11-121-1/+1
|
* Replace all occurences of av_mallocz_array() by av_calloc()Andreas Rheinhardt2021-09-201-2/+2
| | | | | | | They do the same. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
* hwcontext_vulkan: use GPU memcpy when copying to system RAMLynne2021-08-141-6/+6
| | | | This should speed it up significantly on systems where it matters.
* hwcontext_vulkan: fix typo in vulkan_device_init()Lynne2021-06-101-1/+1
| | | | load_functions() did not load the device-level functions.
* hwcontext_vulkan: dlopen libvulkanLynne2021-04-301-4/+47
| | | | | | | | | | | | While Vulkan itself went more or less the way it was expected to go, libvulkan didn't quite solve all of the opengl loader issues. It's multi-vendor, yes, but unfortunately, the code is Google/Khronos QUALITY, so suffers from big static linking issues (static linking on anything but OSX is unsupported), has bugs, and due to the prefix system used, there are 3 or so ways to type out functions. Just solve all of those problems by dlopening it. We even have nice emulation for it on Windows.
* hwcontext_vulkan: dynamically load functionsLynne2021-04-301-147/+365
| | | | This patch allows for alternative loader implementations.
* avutil/hwcontext_vulkan: fix format specifiers for some printed variablesJames Almer2021-04-291-3/+3
| | | | | | | | | | VkPhysicalDeviceLimits.optimalBufferCopyRowPitchAlignment and VkPhysicalDeviceExternalMemoryHostPropertiesEXT.minImportedHostPointerAlignment are of type VkDeviceSize (a typedef uint64_t). VkPhysicalDeviceLimits.minMemoryMapAlignment is of type size_t. Signed-off-by: James Almer <jamrial@gmail.com> Reviewed-by: Lynne <dev@lynne.ee>
* avutil/buffer: Switch AVBuffer API to size_tAndreas Rheinhardt2021-04-271-1/+1
| | | | | | | Announced in 14040a1d913794d9a3fd6406a6d8c2f0e37e0062. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com> Signed-off-by: James Almer <jamrial@gmail.com>
* avutil: use the buffer_size_t typedef where requiredJames Almer2021-03-101-1/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutils/vulkan: hwmap, respect src frame resolutionXu Guangxin2021-01-221-5/+4
| | | | | | | | | | | | | fixes http://trac.ffmpeg.org/ticket/9055 The hw decoder may allocate a large frame from AVHWFramesContext, and adjust width and height based on bitstream. We need to use resolution from src frame instead of AVHWFramesContext. test command: ffmpeg -loglevel debug -hide_banner -hwaccel vaapi -init_hw_device vaapi=va:/dev/dri/renderD128 -hwaccel_device va -hwaccel_output_format vaapi -init_hw_device vulkan=vulk -filter_hw_device vulk -i 1920x1080.264 -c:v libx264 -r:v 30 -profile:v high -preset veryfast -vf "hwmap,chromaber_vulkan=0:0,hwdownload,format=nv12" -map 0 -y vaapiouts.mkv expected: No green bar at bottom.
* hwcontext_vulkan: wait and signal semaphores when transferring to CUDALynne2020-12-051-0/+16
| | | | | Same as when downloading. Not sure why this isn't done, probably because the CUDA code predates the sync mechanism we settled on.
* hwcontext_vulkan: reduce priority for PACK32 formatsLynne2020-11-271-2/+5
| | | | Due to some endian-dependent overlap, these should be used last.