lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ