[FFmpeg-devel] [PATCH v7 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
Lynne
dev at lynne.ee
Wed Aug 30 11:38:47 EEST 2023
Aug 30, 2023, 04:27 by tong1.wu-at-intel.com at ffmpeg.org:
> >Aug 29, 2023, 06:15 by tong1.wu-at-intel.com at 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.
More information about the ffmpeg-devel
mailing list