>-----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. 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.
>_______________________________________________
>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".
