[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70ed7b3197f34c9f3dce9c83c527884c89df5449.camel@ndufresne.ca>
Date: Fri, 28 Jul 2023 12:19:57 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Hsia-Jun Li <Randy.Li@...aptics.com>,
Tomasz Figa <tfiga@...omium.org>
Cc: linux-media@...r.kernel.org, ayaka@...lik.info,
hans.verkuil@...co.com, mchehab@...nel.org,
laurent.pinchart@...asonboard.com, hiroh@...omium.org,
hverkuil@...all.nl, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] media: v4l2-mem2mem: add a list for buf used by hw
Le vendredi 28 juillet 2023 à 15:37 +0800, Hsia-Jun Li a écrit :
> > I think this is one reason to migrate to the stateless decoder design.
> >
> I didn't know such plan here. I don't think the current stateless API
> could export the reconstruction buffers for encoder or post-processing
> 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. This 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 support
Vulkan Video fwiw, and could also help with a transition to DMABuf Heaps and
memory accounting.
I've also had corridor discussion around having multi-instance media constroller
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 (but
massively more complex).
Nicolas
Powered by blists - more mailing lists