On 13/05/2020 16:53, Lynne wrote:
> This, along with the next patch, are the last missing pieces to being 
> interoperable with libplacebo.
> There is no danger of users running into this API break because there are 
> none,
> and API was completely backwards-incompatibly changed just 2 days ago.
> This is needed so we won't have to break the API anymore in the future.

?  The previous change wasn't an ABI break after the fields were rearranged 
properly.

> From 63a95c6848e44f365256dbe10c0e1fa595a0f679 Mon Sep 17 00:00:00 2001
> From: Lynne <d...@lynne.ee>
> Date: Wed, 13 May 2020 16:20:15 +0100
> Subject: [PATCH 1/2] hwcontext_vulkan: expose the amount of queues for each
>  queue family
> 
> This, along with the next patch, are the last missing pieces to being
> interoperable with libplacebo.
> ---
>  libavutil/hwcontext_vulkan.c |  3 +++
>  libavutil/hwcontext_vulkan.h | 14 ++++++++++++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index 8f3f3fdd2a..82ceb7013a 100644
> --- a/libavutil/hwcontext_vulkan.c
> +++ b/libavutil/hwcontext_vulkan.c
> @@ -679,16 +679,19 @@ static int search_queue_families(AVHWDeviceContext 
> *ctx, VkDeviceCreateInfo *cd)
>      hwctx->queue_family_index      = graph_index;
>      hwctx->queue_family_comp_index = graph_index;
>      hwctx->queue_family_tx_index   = graph_index;
> +    hwctx->nb_graphics_queues      = qs[graph_index].queueCount;
>  
>      if (comp_index != -1) {
>          ADD_QUEUE(comp_index, 0, 1, tx_index < 0)
>          hwctx->queue_family_tx_index   = comp_index;
>          hwctx->queue_family_comp_index = comp_index;
> +        hwctx->nb_comp_queues          = qs[comp_index].queueCount;
>      }
>  
>      if (tx_index != -1) {
>          ADD_QUEUE(tx_index, 0, 0, 1)
>          hwctx->queue_family_tx_index = tx_index;
> +        hwctx->nb_tx_queues          = qs[tx_index].queueCount;
>      }
>  
>  #undef ADD_QUEUE
> diff --git a/libavutil/hwcontext_vulkan.h b/libavutil/hwcontext_vulkan.h
> index c3fc14af70..9fbe8b9dcb 100644
> --- a/libavutil/hwcontext_vulkan.h
> +++ b/libavutil/hwcontext_vulkan.h
> @@ -55,16 +55,26 @@ typedef struct AVVulkanDeviceContext {
>       * @note av_hwdevice_create() will set all 3 queue indices if unset
>       * If there is no dedicated queue for compute or transfer operations,
>       * they will be set to the graphics queue index which can handle both.
> +     * nb_graphics_queues indicates how many queues were enabled for the
> +     * graphics queue (must be at least 1)
>       */
>      int queue_family_index;
> +    int nb_graphics_queues;
>      /**
> -     * Queue family index for transfer ops only
> +     * Queue family index to use for transfer operations, and the amount of 
> queues
> +     * enabled. In case there is no dedicated transfer queue, nb_tx_queues
> +     * must be 0 and queue_family_tx_index must be the same as either the 
> graphics
> +     * queue or the compute queue, if available.
>       */
>      int queue_family_tx_index;
> +    int nb_tx_queues;
>      /**
> -     * Queue family index for compute ops
> +     * Queue family index for compute ops, and the amount of queues enabled.
> +     * In case there are no dedicated compute queues, nb_comp_queues must be
> +     * 0 and its queue family index must be set to the graphics queue.
>       */
>      int queue_family_comp_index;
> +    int nb_comp_queues;
>      /**
>       * Enabled instance extensions. By default, VK_KHR_surface is enabled if 
> found.
>       * If supplying your own device context, set this to an array of 
> strings, with
> -- 
> 2.26.2

Put the new fields at the end.  It looks like that combined with zero implying 
the number of queues available in that queue family would be sufficient to 
maintain compatibility?

Under what circumstances would a user create an AVVulkanDeviceContext which 
does not set these to their maximum value?  Will you want to expose some option 
so that a device created by lavu can do the same thing?

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

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

Reply via email to