Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Philip Langdale <philipl@overt.org>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] vulkan: synchronize access to execution pool fences
Date: Wed, 7 Jun 2023 14:30:42 -0700
Message-ID: <20230607143042.2be631bc@fluffy> (raw)
In-Reply-To: <NXI0BZl--3-9@lynne.ee>

On Wed, 7 Jun 2023 01:22:25 +0200 (CEST)
Lynne <dev@lynne.ee> wrote:

> From c79aa3ed01033f515cbb21251e83cb5bafdf83d7 Mon Sep 17 00:00:00 2001
> From: Lynne <dev@lynne.ee>
> Date: Wed, 7 Jun 2023 00:24:43 +0200
> Subject: [PATCH 1/2] vulkan: synchronize access to execution pool
> fences
> 
> vkResetFences is specified as being user-synchronized
> (yet vkWaitFences, is not).
> ---
>  libavcodec/vulkan_decode.c |  2 +-
>  libavutil/vulkan.c         | 12 ++++++++++--
>  libavutil/vulkan.h         |  2 ++
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
> index 889c67a15f..9e3ebf6770 100644
> --- a/libavcodec/vulkan_decode.c
> +++ b/libavcodec/vulkan_decode.c
> @@ -1106,7 +1106,7 @@ int ff_vk_decode_init(AVCodecContext *avctx)
>  
>      /* Create decode exec context.
>       * 4 async contexts per thread seems like a good number. */
> -    err = ff_vk_exec_pool_init(s, &qf_dec, &ctx->exec_pool,
> 4*avctx->thread_count,
> +    err = ff_vk_exec_pool_init(s, &qf_dec, &ctx->exec_pool, 1,
>                                 nb_q,

Comment is now out of date?

> VK_QUERY_TYPE_RESULT_STATUS_ONLY_KHR, 0,
> session_create.pVideoProfile); if (err < 0)
> diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
> index bc4466e6c9..4b96c0c200 100644
> --- a/libavutil/vulkan.c
> +++ b/libavutil/vulkan.c
> @@ -241,6 +241,7 @@ void ff_vk_exec_pool_free(FFVulkanContext *s,
> FFVkExecPool *pool) vk->WaitForFences(s->hwctx->act_dev, 1,
> &e->fence, VK_TRUE, UINT64_MAX); vk->DestroyFence(s->hwctx->act_dev,
> e->fence, s->hwctx->alloc); }
> +        pthread_mutex_destroy(&e->lock);
>  
>          ff_vk_exec_discard_deps(s, e);
>  
> @@ -379,12 +380,17 @@ int ff_vk_exec_pool_init(FFVulkanContext *s,
> FFVkQueueFamilyCtx *qf, /* Init contexts */
>      for (int i = 0; i < pool->pool_size; i++) {
>          FFVkExecContext *e = &pool->contexts[i];
> -
> -        /* Fence */
>          VkFenceCreateInfo fence_create = {
>              .sType = VK_STRUCTURE_TYPE_FENCE_CREATE_INFO,
>              .flags = VK_FENCE_CREATE_SIGNALED_BIT,
>          };
> +
> +        /* Mutex */
> +        err = pthread_mutex_init(&e->lock, NULL);
> +        if (err != 0)
> +            return AVERROR(err);
> +
> +        /* Fence */
>          ret = vk->CreateFence(s->hwctx->act_dev, &fence_create,
> s->hwctx->alloc, &e->fence);
>          if (ret != VK_SUCCESS) {
> @@ -489,8 +495,10 @@ int ff_vk_exec_start(FFVulkanContext *s,
> FFVkExecContext *e) };
>  
>      /* Create the fence and don't wait for it initially */
> +    pthread_mutex_lock(&e->lock);
>      vk->WaitForFences(s->hwctx->act_dev, 1, &e->fence, VK_TRUE,
> UINT64_MAX); vk->ResetFences(s->hwctx->act_dev, 1, &e->fence);
> +    pthread_mutex_unlock(&e->lock);

If WaitForFences doesn't require synchronisation, would it be desirable
to call it outside the mutex locking? 

Otherwise, LGTM.

--phil
_______________________________________________
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".

      parent reply	other threads:[~2023-06-07 21:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-06 23:22 Lynne
     [not found] ` <NXI0BZl--3-9@lynne.ee-NXI0Fb7----9>
2023-06-06 23:23   ` [FFmpeg-devel] [PATCH 2/2] vulkan: discard dependencies when explicitly waiting for execution Lynne
2023-06-07 21:32     ` Philip Langdale
2023-06-07 22:06       ` Lynne
2023-06-06 23:45   ` [FFmpeg-devel] [PATCH 1/2] vulkan: synchronize access to execution pool fences Lynne
     [not found]   ` <NXI5POg--3-9@lynne.ee-NXI5TBx----9>
2023-06-06 23:59     ` Lynne
2023-06-07 21:31       ` Philip Langdale
2023-06-07 22:06         ` Lynne
2023-06-07 21:30 ` Philip Langdale [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230607143042.2be631bc@fluffy \
    --to=philipl@overt.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git