>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?
Actually d3d12va_wait_idle is just a query of timeline fence. At most of time, the block wait is not triggered. It only gets the fence value to know if the GPU command is completed. It's a known d3d12 design for high performance and for users to sync with GPU completion. The function name might be a bit confusing. I may change the name from "wait" to "sync" in the next version. Thanks, Tong > > >> 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". _______________________________________________ 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".