Aug 30, 2023, 04:27 by [email protected]: > >Aug 29, 2023, 06:15 by [email protected]: > >>> + >>> + /** >>> + * 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. _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
