From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4E13F46195 for ; Wed, 7 Jun 2023 21:30:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8ED2568B20A; Thu, 8 Jun 2023 00:30:51 +0300 (EEST) Received: from mail.overt.org (mail.overt.org [72.14.183.176]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1E3C068B20A for ; Thu, 8 Jun 2023 00:30:45 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=overt.org; s=mail; t=1686173443; bh=6NqAQTw5ONT7OXR5EJJMF9gEFxzjw7oo4pbsSSifdWQ=; h=Date:From:To:Subject:In-Reply-To:References:From; b=HNIsDCP3L9fDQ1zsheFj7BZM4zyyDgfxv7KFbV2M13Bah/3VCmixSVwB8OjrXlSzG QCecKw8Vf8XPcTJkoshRC09C4YAycleEADXflJHBJ2p5QJKjf+OtFTftDP/LVDYdlx JYDk61Xtqu+D0AwOoeGxOM5uzpjuFvn5wjLup0LdfXNkh5vtH0b4PN8hiuYWVXwP+u IMlf0VS+w8Ewto/OSSm92JtU3CVlsVIjyeWSadV4u83+39M4U9Jq44hxs9pzx6vC+0 /QMhvo3/YEgEnhLP6uOvv7eIB3B6/4IDDIpl36ZUhCSUiJZlXUnmOlD8WcsM9wTbI1 x4bpX0YdSGL7w== Received: from authenticated-user (mail.overt.org [72.14.183.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.overt.org (Postfix) with ESMTPSA id B26BD60389 for ; Wed, 7 Jun 2023 16:30:43 -0500 (CDT) Date: Wed, 7 Jun 2023 14:30:42 -0700 From: Philip Langdale To: ffmpeg-devel@ffmpeg.org Message-ID: <20230607143042.2be631bc@fluffy> In-Reply-To: References: MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/2] vulkan: synchronize access to execution pool fences X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Wed, 7 Jun 2023 01:22:25 +0200 (CEST) Lynne wrote: > From c79aa3ed01033f515cbb21251e83cb5bafdf83d7 Mon Sep 17 00:00:00 2001 > From: Lynne > 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".