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

[Lynne <dev@lynne.ee>]

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