Le jeudi 17 février 2022 à 17:03 +0800, yunfei.dong@xxxxxxxxxxxx a écrit :
> > > - ret = vdec_if_decode(ctx, bs_src, dst_buf, &res_chg);
> > > + ret = vdec_if_decode(ctx, bs_src, NULL, &res_chg);
> > > if (ret) {
> > > mtk_v4l2_err(" <===[%d], src_buf[%d] sz=0x%zx pts=%llu
> > > vdec_if_decode() ret=%d res_chg=%d===>",
> > > ctx->id, vb2_src->index, bs_src->size,
> > > @@ -220,12 +266,9 @@ static void mtk_vdec_worker(struct work_struct
> > > *work)
> > > }
> > > }
> > >
> > > - mtk_vdec_stateless_set_dst_payload(ctx, dst_buf);
> > > -
> > > - v4l2_m2m_buf_done_and_job_finish(dev->m2m_dev_dec, ctx-
> > > > m2m_ctx,
> > > - ret ? VB2_BUF_STATE_ERROR :
> > > VB2_BUF_STATE_DONE);
> > > -
> > > + mtk_vdec_stateless_out_to_done(ctx, bs_src, ret);
> >
> > v4l2_m2m_buf_done_and_job_finish() was specially crafted to prevent
> > developer
> > from implementing the signalling of the request at the wrong moment.
> > This patch
> > broke this strict ordering. The relevant comment in the helper
> > function:
> >
> >
> As we discussed in chat, please help to check whether it's possible to
> let lat and core decode in parallel.
Thanks, Benjamin is looking into that. For the mailing list here, here's some
prior art for a similar problem found by downstream RPi4 HEVC driver developer.
The general problem here is that we don't want to signal the request until the
decode have complete, yet we want to pick and run second (concurrent job) so
that parallel decoding is made possible. For RPi4 it is not multi-core, but the
decoding is split in 2 stages, and the decoder run both stages concurrently,
which basically means, we need to be able to run two jobs at the same time
whenever possible.
https://github.com/raspberrypi/linux/commit/964be1d20e2f1335915a6bf8c82a3199bfddf8ac
This introduce media_request_pin/unpin, but being able to pin a request and not
have it bound to any other object lifetime anymore seems a bit error prone in
comparison to the current restrictions. Comments welcome !
>
> I will continue to fix h264 issue.
Thanks.
>
> Thanks for your help.
>
> Best Regards,
> Yunfei Dong
