aboutsummaryrefslogtreecommitdiffstats
path: root/libavutil/hwcontext_vulkan.c
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* hwcontext_vulkan: add the mapped software frame as an upload dependencyLynne2024-11-181-1/+11
| | | | | | | | | We do uploads asynchronously, and we map the software frames in order to avoid 2-stage copying. However, whilst we added a dependency upon the mapped buffers, we did not add the original frame backing those buffers as a dependency. This caused issues on RADV, particularly with RGB images.
* vulkan: add support for 10-bit planar RGBLynne2024-11-181-0/+1
|
* hwcontext_vulkan: fix planar RGB imagesLynne2024-11-181-12/+13
| | | | They were non-working for quite a while.
* avutil/hwcontext_vulkan: add missing packed YUV444 format mappingsJames Almer2024-10-271-1/+6
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* avutil/hwcontext_vulkan: add support for AV_PIX_FMT_Y216James Almer2024-10-231-0/+1
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* hwcontext_vulkan: always enable MUTABLE creation flagLynne2024-10-161-3/+3
| | | | | We need it even for something as simple as bitexact opening of images.
* vulkan: add support for AV_PIX_FMT_RGB96Lynne2024-10-151-0/+1
|
* vulkan: add support for AV_PIX_FMT_RGBA128Lynne2024-10-151-0/+1
|
* avutil/hwcontext_vulkan: add proper maps for XV3{0,6}James Almer2024-10-141-5/+4
| | | | Signed-off-by: James Almer <jamrial@gmail.com>
* hwcontext_vulkan: enable shaderBufferInt64Atomics if supportedLynne2024-10-111-0/+1
|
* hwcontext_vulkan: add support for AV_PIX_FMT_RGBF32Lynne2024-10-111-0/+1
|
* hwcontext_vulkan: add support for AV_PIX_FMT_RGBAF32Lynne2024-10-111-0/+1
|
* hwcontext_vulkan: set hwctx->device_featuresLynne2024-10-091-0/+3
| | | | This was forgotten during the recent device feature refactor.
* hwcontext_vulkan: remove redundant hostQueryReset settingLynne2024-10-091-1/+0
| | | | Its set just a few lines earlier.
* hwcontext_vulkan: guard all uses of new spec defines and fix stray bracketLynne2024-10-041-1/+4
| | | | This fixes compilation with less recent Vulkan headers.
* vulkan: add profiling debug settingLynne2024-10-041-5/+17
| | | | | This simply keeps all shader optimizations, but allows debug data to be generated.
* vulkan: parse instance list and add the DEBUG_UTILS extensionLynne2024-10-041-1/+0
| | | | Required to let users know whether debugging is active.
* hwcontext_vulkan: move device feature struct setup to a new functionLynne2024-10-041-180/+155
|
* hwcontext_vulkan: enable VK_KHR_shader_relaxed_extended_instructionLynne2024-10-041-0/+39
|
* vulkan: always enable GL_EXT_scalar_block_layoutLynne2024-10-041-0/+1
| | | | | | This makes std430 (which we use everywhere already) fully match C layout. Extension was made mandatory in 1.2.
* vulkan: check if current buffer has finished execution before picking anotherLynne2024-10-041-3/+3
| | | | | This saves resources, as dependencies are freed/reclaimed with a lower latency, and provies a speedup.
* vulkan: use push descriptors where possibleLynne2024-09-231-1/+1
| | | | | | | | Push descriptors are in theory slightly faster, but come with limitations for which we have to check. Either way, they're not difficult to implement, so even though no one should be using peasant-tier descriptors, do it anyway.
* vulkan: add support for regular descriptor poolsLynne2024-09-231-0/+6
| | | | | | | | | | | | | This permits: - The use of Vulkan filtering on many more devices - Better debugging due to lack of descriptor buffer support in layers Much of the changes here are due to a requirement that updates to descriptors must happen between the command buffer being waited on, and the pipeline not being bound. We routinely did it the other way around, by updating only after we bind the pipeline.
* hwcontext_vulkan: forward debug_mode to check_extensions() for devicesLynne2024-09-231-12/+13
| | | | This allows disabling of certain extensions when debug mode is turned on.
* hwcontext_vulkan: add the PROFILE_INDEPENDENT only when neededLynne2024-09-231-1/+2
|
* hwcontext_vulkan: add support for implicit DRM synchronizationLynne2024-09-221-11/+137
| | | | | | | | | | | | | | | | | | | More recent kernel versions allow for users to extract a sync_file handle from a DMA-BUF, which can then be imported into Vulkan as a binary semaphore. This finally allows for synchronization between Vulkan and DMA-BUF images, such as those from screen capture software, or VAAPI, avoiding any corruption artifacts. This is done fully asynchronously, where we use the kernel's given binary semaphores as a dependency to increment the image's usual VkSemaphores we allocate. The old imported binary semaphores are cleaned up after execution as usual. In the future, hwcontext_drm should receive support for explicitly synchronized images as well, which would make the synchronization more robust and portable.
* hwcontext_vulkan: fix ↵Lynne2024-09-221-8/+10
| | | | | | VUID-VkPhysicalDeviceImageFormatInfo2-usage-requiredbitmask fmt_props.usage was initialized to 0 as create_info.usage was set later.
* hwcontext_vulkan: consider encode DBPs as always independentLynne2024-09-181-2/+3
|
* hwcontext_vulkan: fix p->img_qfsLynne2024-09-181-1/+16
| | | | | The array was tied to our old queue API, which meant that if users set it, it was never set.
* hwcontext_vulkan: add support for x2bgr10 and proper DRM mappings for 10-bit ↵Lynne2024-09-161-0/+5
| | | | | | images This allows mapping of 10-bit DRM images.
* hwcontext_vulkan: disable more false positive validation checksLynne2024-09-091-0/+3
| | | | | | | Both of these are fundamentally incompatible with video decoding. The third one can be tracked in the following validation layer issue: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/6627
* hwcontext_vulkan: ask for storage images by defaultLynne2024-09-091-2/+4
| | | | | | | The issue is that we ask for storage images by default if available, but because that is gated by the format supporting storage images, and the check for the format supporting storage images is gated by the usage, this resulted in a catch-22.
* hwcontext_vulkan: add PREP_MODE_GENERAL for non-transfer_dst imagesLynne2024-09-091-1/+8
| | | | Vulkan filters don't need images which can be transferred into.
* hwcontext_vulkan: align host mapping size to minImportedHostPointerAlignmentLynne2024-08-161-0/+1
| | | | This was left out of the recent rewrite of the system.
* vulkan: enable encoding of images if video_maintenance1 is enabledLynne2024-08-161-0/+28
| | | | | | | | | | Vulkan encoding was designed in a very... consolidated way. You had to know the exact codec and profile that the image was going to eventually be encoded as at... image creation time. Unfortunately, as good as our code is, glimpsing into the exact future isn't what its capable of. video_maintenance1 removed that requirement, which only then made encoding images practically possible.
* hwcontext_vulkan: enable VK_KHR_video_maintenance1Lynne2024-08-161-1/+11
| | | | We require it for encoding.
* hwcontext_vulkan: setup extensions before featuresLynne2024-08-161-35/+38
| | | | | | The issue is that enabling features requires that the device extension is supported. The extensions bitfield was set later, so it was always 0, leading to no features being added.
* hwcontext_vulkan: don't enable deprecated VK_KHR_sampler_ycbcr_conversion ↵Lynne2024-08-161-1/+0
| | | | | | | extension It was added to Vulkan 1.1 a long time ago. Validation layer will warn if this is enabled.
* hwcontext_vulkan: fix user layers, add support for different debug modesLynne2024-08-161-72/+145
| | | | | | | | | The validation layer option only supported GPU-assisted validation. This is mutually exclusive with shader debug printfs, so we need to differentiate between the two. This also fixes issues with user-given layers, and leaks in case of errors.
* hwcontext_vulkan: ignore false positive validation errorsLynne2024-08-111-1/+9
| | | | | Issue ref: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/6627
* hwcontext_vulkan: do not chain structs of unsupported extensions in ↵Lynne2024-08-111-11/+21
| | | | | | | | | | | | | vkCreateDevice Fixes: vkCreateDevice(): pCreateInfo->pNext<VkPhysicalDeviceOpticalFlowFeaturesNV> includes a pointer to a VkPhysicalDeviceOpticalFlowFeaturesNV, but when creating VkDevice, the parent extension (VK_NV_optical_flow) was not included in ppEnabledExtensionNames. The Vulkan spec states: Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid struct for extending VkDeviceCreateInfo.
* libavutil: deprecate the old Vulkan queue API, add doc/APIchanges entriesLynne2024-08-111-0/+8
|
* hwcontext_vulkan: add support for Vulkan encodingLynne2024-08-111-0/+10
|
* hwcontext_vulkan: add support for VK_EXT_shader_objectLynne2024-08-111-2/+12
| | | | | We'd like to use it eventually, and its already covered by the minimum version of the headers we require.
* hwcontext_vulkan: enable storageBuffer16BitAccess if availableLynne2024-08-111-0/+2
|
* hwcontext_vulkan: constify validation layer features tableLynne2024-08-111-1/+1
| | | | | The struct data seem to get corrupted otherwise. Possibly a validation layer or libvulkan issue.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-07 18:12:18 +0000