Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <70ed7b3197f34c9f3dce9c83c527884c89df5449.camel@ndufresne.ca>
Subject: Re: [PATCH 2/2] media: v4l2-mem2mem: add a list for buf used by hw
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Hsia-Jun Li <Randy.Li@synaptics.com>,
        Tomasz Figa <tfiga@chromium.org>
Cc:     linux-media@vger.kernel.org, ayaka@soulik.info,
        hans.verkuil@cisco.com, mchehab@kernel.org,
        laurent.pinchart@ideasonboard.com, hiroh@chromium.org,
        hverkuil@xs4all.nl, linux-kernel@vger.kernel.org
Date:   Fri, 28 Jul 2023 12:19:57 -0400
In-Reply-To: <10ad26e6-b2d0-d0e6-40c8-2cc70613188b@synaptics.com>
References: <20230704040044.681850-1-randy.li@synaptics.com>
         <20230704040044.681850-3-randy.li@synaptics.com>
         <20230712093301.nkj2vok2x7esdhb3@chromium.org>
         <f8f766c0166c502e29b06cda71f6531e44a91a17.camel@ndufresne.ca>
         <CAAFQd5CO4TS6wMsnaL7ob4CXogj5KT52x85YUUN1ZwDkOxW0oQ@mail.gmail.com>
         <583e22718b80cc5e1ae631528c83c95e97de5cae.camel@ndufresne.ca>
         <CAAFQd5CAJ7GxiY5=bBAa+L=1WJth6QZ3+PG83=GX+eEx1S4uhg@mail.gmail.com>
         <7d340df3-e14c-24de-4fc2-b7dca619447c@synaptics.com>
         <CAAFQd5BKHQPNVpDvpQaFn-q721BJknJCUB72urc2=EKsAH=OCg@mail.gmail.com>
         <10ad26e6-b2d0-d0e6-40c8-2cc70613188b@synaptics.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

Le vendredi 28 juillet 2023 =C3=A0 15:37 +0800, Hsia-Jun Li a =C3=A9crit=C2=
=A0:
> > I think this is one reason to migrate to the stateless decoder design.
> >=20
> I didn't know such plan here. I don't think the current stateless API=20
> could export the reconstruction buffers for encoder or post-processing=
=20
> buffer for decoder to us.

Someone suggested introduce auxiliary queues in our meeting in Lyon a while=
 ago,
but I bet everyone got too busy with finalizing APIs, fixing fluster tests =
etc.
The suggestion felt like it would be possible to add it after the fact. Thi=
s was
also being discussed in the context of supporting multi-scalers (standalone=
 our
inline with the codec, like VC8000D+). It could also cover for primary and
secondary buffers, along with encoder primary, and reconstruction buffers, =
but
also auxiliary reference data. This would also be needed to properly suppor=
t
Vulkan Video fwiw, and could also help with a transition to DMABuf Heaps an=
d
memory accounting.

I've also had corridor discussion around having multi-instance media constr=
oller
devices. It wasn't clear how to bind the media instance to the video node
instances, but assuming there is a way, it would be a tad more flexible (bu=
t
massively more complex).

Nicolas