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

[Lynne <dev@lynne.ee>]

Aug 30, 2023, 11:05 by tong1.wu-at-intel.com@ffmpeg.org:

>
>
> >-----Original Message-----
> >From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> >Sent: Wednesday, August 30, 2023 4:39 PM
> >To: FFmpeg development discussions and patches <ffmpeg-
> >devel@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@ffmpeg.org:
>
>>> >Aug 29, 2023, 06:15 by tong1.wu-at-intel.com@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?


>  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-request@ffmpeg.org with subject "unsubscribe".