Re: [FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: add a new mechanism to expose used queue families

[Anton Khirnov <anton@khirnov.net>]

Quoting Lynne via ffmpeg-devel (2024-07-10 01:56:57)
> On 09/07/2024 08:57, Anton Khirnov wrote:
> > Quoting Lynne via ffmpeg-devel (2024-07-09 03:07:12)
> >> @@ -151,6 +162,17 @@ typedef struct AVVulkanDeviceContext {
> >>        * Similar to lock_queue(), unlocks a queue. Must only be called after locking.
> >>        */
> >>       void (*unlock_queue)(struct AVHWDeviceContext *ctx, uint32_t queue_family, uint32_t index);
> >> +
> >> +    /**
> >> +     * Queue families used. Must be preferentially ordered. List may contain
> >> +     * duplicates, as long as their capability flags do not match.
> >> +     *
> >> +     * For compatibility reasons, all the enabled queue families listed above
> >> +     * (queue_family_(tx/comp/encode/decode)_index) must also be included in
> >> +     * this list until they're removed after deprecation.
> >> +     */
> >> +    AVVulkanDeviceQueueFamily qf[16];
> > 
> > Why 16? And are we really really sure sizeof(AVVulkanDeviceQueueFamily)
> > should be a part of the ABI?
> 
> 16 is just an arbitrary limit. I don't expect to need more than this 
> ever, but if we do, its not something that we can't wait until a bump 
> occurs.
> I can increase it to 32 if you're concerned about it.
> 
> There are 6 total queue family types, and 6 more currently supported 
> encode and decode operations for each queue -> 12.
> 
> I'd like to avoid making this not a part of the ABI, particularly as its 
> a context that users should be able to easily set themselves.

I'm more concerned about adding new fields to AVVulkanDeviceQueueFamily.
Can't you just make qf an array of pointers, with a new function that
adds a new queue family to it?

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".