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

Wu, Tong1 tong1.wu at intel.com
Wed Aug 30 12:05:28 EEST 2023



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


More information about the ffmpeg-devel mailing list