Aug 30, 2023, 11:05 by tong1.wu-at-intel....@ffmpeg.org: > > > >-----Original Message----- > >From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Lynne > >Sent: Wednesday, August 30, 2023 4:39 PM > >To: FFmpeg development discussions and patches <ffmpeg- > >de...@ffmpeg.org> > >Subject: Re: [FFmpeg-devel] [PATCH v7 1/9] libavutil: add hwcontext_d3d12va > >and AV_PIX_FMT_D3D12 > >> >> > >Aug 30, 2023, 04:27 by tong1.wu-at-intel....@ffmpeg.org: > >>> >Aug 29, 2023, 06:15 by tong1.wu-at-intel....@ffmpeg.org: >>> >>>>> + >>>>> + /** >>>>> + * Specifed by sync=1 when init d3d12va >>>>> + * >>>>> + * Execute commands as sync mode >>>>> + */ >>>>> + int sync; >>>>> >>> >This is not needed, particularly in the public API. >>> >>>>> + if (download) { >>>>> + ID3D12GraphicsCommandList_ResourceBarrier(s->command_list, 1, >>>>> >>> >&barrier); >>> >>>>> + >>>>> + ID3D12GraphicsCommandList_CopyTextureRegion(s->command_list, >>>>> + &staging_y_location, 0, 0, 0, &texture_y_location, NULL); >>>>> + >>>>> + ID3D12GraphicsCommandList_CopyTextureRegion(s->command_list, >>>>> + &staging_uv_location, 0, 0, 0, &texture_uv_location, NULL); >>>>> + >>>>> + barrier.Transition.StateBefore = barrier.Transition.StateAfter; >>>>> + barrier.Transition.StateAfter = D3D12_RESOURCE_STATE_COMMON; >>>>> + ID3D12GraphicsCommandList_ResourceBarrier(s->command_list, 1, >>>>> >>> >&barrier); >>> >>>>> + >>>>> + DX_CHECK(ID3D12GraphicsCommandList_Close(s->command_list)); >>>>> + >>>>> + if (!hwctx->sync) >>>>> + DX_CHECK(ID3D12CommandQueue_Wait(s->command_queue, >>>>> >>> >sync_ctx->fence, sync_ctx->fence_value)); >>> >>>> >>>> >>> >This is wrong. When downloading to RAM, the frames must >>> >always be available and fully downloaded by the time the function >>> >returns. Therefore, a wait must always occur. >>> >Since this is the only place where sync is used, better remove the >>> >option altogether. >>> >>> There's another place where it's used. It's designed for API users to >>> blocking >>> > >wait every decoded frame. > >>> In end_frame() call in d3d12va_decode.c. >>> >>> if (ctx->device_ctx->sync) { >>> ret = d3d12va_wait_idle(ctx->sync_ctx); >>> if (ret < 0) >>> return ret; >>> } >>> >>> That's why when downloading, you don't have to wait again if hwctx->sync is >>> > >specified. The frame has already been blocking synced in decoding process. > >>> >>> But yes I agree it's not that needed. I'll remove the whole design in next >>> > >version. > >>> >>> > >That's not correct either, waiting should happen at the last possible moment, > >rather than immediately after decoding, and waiting should happen > >asynchronously > >on the GPU, rather than the CPU. > >> >> > >Would you mind holding off on posting the redesign until v6.1 is tagged? > >Thanks. > > I've already sent the v8 with the removal of the design. >
The code is still present in v8 though, the d3d12va_wait_idle() call in ff_d3d12va_common_end_frame. Is there no way to wait for the operation on the GPU by recording it in the command buffer? > But yes it's ok for me to wait for 6.1 tagged and rebase again after that. > BTW is there any schedule for 6.1? Haven't seen a lot of discussions on that > recently. Thanks. > Thanks. _______________________________________________ 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".