[FFmpeg-devel] [PATCH] Vulkan hwcontext and filters
Lynne
dev at lynne.ee
Tue Jan 21 19:51:22 EET 2020
Jan 21, 2020, 12:08 by anton at khirnov.net:
> Quoting Lynne (2020-01-10 22:05:21)
>
>> /**
>> * Activated physical device
>> */
>> VkDevice act_dev;
>>
>
> Where is this 'activated' terminology from? From what I can see, the
> spec calls this a 'logical' device. Would be nice to be consistent with
> it.
>
Its just the current active device. Not really wanting to change it, its pretty clear what it is from the type.
>> /**
>> * Queue family index for graphics
>> */
>> int queue_family_index;
>>
>
> What is this for? I don't see it used anywhere.
>
Its required to do anything graphics-related (like non-compute shaders, which lavfi will support in a future patch). You need to know it at init time and at runtime, and there's nothing you can call to know what its been initialized as.
>> /**
>> * Queue family index for transfer ops only. By default, the priority order
>> * is dedicated transfer > dedicated compute > graphics.
>> */
>>
>
> IIUC the second sentence talks about how the internal device
> creation/derivation code works, but that isn't made very clear. Maybe
> make it a
> @note the av_hwdevice_create() will set those fields like this...
>
Done.
>> int queue_family_tx_index;
>> /**
>> * Queue family index for compute ops. Will be equal to the graphics
>> * one unless a dedicated transfer queue is found.
>> */
>> int queue_family_comp_index;
>>
>
> Same comment as above.
>
Fixed.
>> /**
>> * The UUID of the selected physical device.
>> */
>> uint8_t device_uuid[VK_UUID_SIZE];
>>
>
> Do we really need to export this here? It can be queried from phys_dev,
> no?
>
Actually no, so removed it and changed hwcontext_cuda to use vkGetPhysicalDeviceProperties2.
>> } AVVulkanDeviceContext;
>>
>> /**
>> * Allocated as AVHWFramesContext.hwctx, used to set pool-specific options
>> */
>> typedef struct AVVulkanFramesContext {
>> /**
>> * Controls the tiling of output frames.
>> */
>> VkImageTiling tiling;
>> /**
>> * Defines extra usage of output frames. This is bitwise OR'd with the
>> * standard usage flags (SAMPLED, STORAGE, TRANSFER_SRC and TRANSFER_DST).
>> */
>> VkImageUsageFlagBits usage;
>> /**
>> * Extension data for image creation. By default, if the extension is
>> * available, this will be chained to a VkImageFormatListCreateInfoKHR.
>> */
>> void *create_pnext;
>> /**
>> * Extension data for memory allocation. Must have as many entries as
>> * the number of planes of the sw_format.
>> * This will be chained to VkExportMemoryAllocateInfo, which is used
>> * to make all pool images exportable to other APIs.
>> */
>> void *alloc_pnext[AV_NUM_DATA_POINTERS];
>> } AVVulkanFramesContext;
>>
>> /*
>> * Frame structure, the VkFormat of the image will always match
>> * the pool's sw_format.
>> * All frames, imported or allocated, will be created with the
>> * VK_IMAGE_CREATE_ALIAS_BIT flag set, so the memory may be aliased if needed.
>> */
>> typedef struct AVVkFrame {
>> /**
>> * Vulkan images to which the memory is bound to.
>> */
>> VkImage img[AV_NUM_DATA_POINTERS];
>>
>> /**
>> * Same tiling must be used for all images.
>> */
>> VkImageTiling tiling;
>>
>> /**
>> * Memory backing the images. Could be less than the amount of images
>> * if importing from a DRM or VAAPI frame.
>> */
>> VkDeviceMemory mem[AV_NUM_DATA_POINTERS];
>> size_t size[AV_NUM_DATA_POINTERS];
>>
>> /**
>> * OR'd flags for all memory allocated
>> */
>> VkMemoryPropertyFlagBits flags;
>>
>> /**
>> * Updated after every barrier
>> */
>> VkAccessFlagBits access[AV_NUM_DATA_POINTERS];
>> VkImageLayout layout[AV_NUM_DATA_POINTERS];
>>
>> /**
>> * Per-image semaphores. Must not be freed manually. Must be waited on
>> * and signalled at every queue submission.
>> */
>> VkSemaphore sem[AV_NUM_DATA_POINTERS];
>>
>> /**
>> * Internal data.
>> */
>> struct AVVkFrameInternal *internal;
>> } AVVkFrame;
>>
>
> This is a pretty big and complicated struct and its size has to be
> hardcoded in the ABI IIUC. Do we want a constructor for it?
>
Its size too? Didn't know that.
I do think its a good idea to be able to append fields to it, so I've added a av_vk_frame_alloc() function. I've followed what av_frame_alloc is called, though I'm not sure if its too close to that one's name.
Changes are in git.
More information about the ffmpeg-devel
mailing list