[FFmpeg-devel] [PATCH v7 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12

[Wu, Tong1]

>Aug 30, 2023, 11:05 by tong1.wu-at-intel.com at ffmpeg.org:
>
>>
>>
>> >-----Original Message-----
>> >From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>Lynne
>> >Sent: Wednesday, August 30, 2023 4:39 PM
>> >To: FFmpeg development discussions and patches <ffmpeg-
>> >devel at 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.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.
>>
>> 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 at ffmpeg.org
>https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>To unsubscribe, visit link above, or email
>ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".