From: Hsia-Jun Li <Randy.Li@synaptics.com>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: linux-kernel@vger.kernel.org,
"Paul Kocialkowski" <paul.kocialkowski@bootlin.com>,
linux-media@vger.kernel.org, "Hans Verkuil" <hverkuil@xs4all.nl>,
"Sakari Ailus" <sakari.ailus@iki.fi>,
"Andrzej Pietrasiewicz" <andrzej.p@collabora.com>,
"Michael Tretter" <m.tretter@pengutronix.de>,
"Jernej Škrabec" <jernej.skrabec@gmail.com>,
"Chen-Yu Tsai" <wens@csie.org>,
"Samuel Holland" <samuel@sholland.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
Date: Thu, 27 Jul 2023 10:45:01 +0800 [thread overview]
Message-ID: <b2d75cf6-2e57-65ab-ebf1-caaa17f479e0@synaptics.com> (raw)
In-Reply-To: <87cfcdfadee89984496c3f52d01b4f1e10c12cae.camel@collabora.com>
On 7/27/23 03:53, Nicolas Dufresne wrote:
> CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hi,
>
> Le mercredi 26 juillet 2023 à 10:49 +0800, Hsia-Jun Li a écrit :
>>> I am strongly against this approach, instead I think we need to keep all
>>> vendor-specific parts in the kernel driver and provide a clean unified userspace
>>> API.
>>>
>> We are driving away vendor participation. Besides, the current design is
>> a performance bottleneck.
>
> I know you have been hammering this argument for many many years. But in
> concrete situation, we have conducted tests, and we out perform vendors stacks
> that directly hit into hardware register with stateless CODEC. Also, Paul's
> proposal, is that fine grain / highly close to metal tuning of the encoding
> process should endup in the Linux kernel, so that it can benefit from the
> natural hard real-time advantage of a hard IRQ. Just like anything else, we will
In a real case, especially in those EDR/DVR, NVR, re-encoding could
happen occasionally. The important is feedback the encoded statistic to
the controller(userspace) then userspace decided the future
operation(whether re-encoding this or not).
> find a lot of common methods and shareable code which will benefit in security
The security for a vendor would only mean the protection of its
intelligence properties. Also userspace and HAL is isolated in Android.
Security or quality are not a problem here, you can't even run the
unverified code.
Or we just define an interface that only FOSS would use.
> and quality, which is very unlike what we normally get from per vendor BSP. The
> strategy is the same as everything else in Linux, vendor will adpot it if there
> is a clear benefit. And better quality, ease of use, good collection of mature
Any vendor would like to implement a DRM(digital right, security) video
pipeline would not even think of this. They are not many vendors that
just sell plain video codecs hardware.
In such case, we can't even invoke in its memory management, they may
even drop the V4L2 framework.
Somebody may say why the vendor want the stateless codec, they could
have a dedicated core to run a firmware. It is simple, if you are
comparing an ARM cortex-R/M core to an ARM application core, which one
could performance better? A remote processor could make the memory
model(cache coherent) more complex. Besides, it is about the cost.
> userspace software is what makes the difference. It does takes time of course.
Anyway, despite those registers and controls part, I think I could input
the buffer management part here.
Please DO ***NOT*** make a standard that occupied many memory behinds
usersace and a standard that user has to handle the reconstruction
buffer holding with a strange mechanism(I mean reconstruction buffer
lifetime would be manged by userspace manually).
>
> regards,
> Nicolas
--
Hsia-Jun(Randy) Li
next prev parent reply other threads:[~2023-07-27 2:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 17:12 Stateless Encoding uAPI Discussion and Proposal Paul Kocialkowski
2023-07-11 18:18 ` Nicolas Dufresne
2023-07-12 14:07 ` Paul Kocialkowski
2023-07-25 3:33 ` Hsia-Jun Li
2023-07-25 12:15 ` Paul Kocialkowski
2023-07-26 2:49 ` Hsia-Jun Li
2023-07-26 19:53 ` Nicolas Dufresne
2023-07-27 2:45 ` Hsia-Jun Li [this message]
2023-07-27 17:10 ` Nicolas Dufresne
2023-07-26 8:18 ` Hans Verkuil
2023-08-09 14:43 ` Paul Kocialkowski
2023-08-09 17:24 ` Andrzej Pietrasiewicz
2023-07-21 18:19 ` Michael Grzeschik
2023-07-24 14:03 ` Nicolas Dufresne
2023-07-25 9:09 ` Paul Kocialkowski
2023-07-26 20:02 ` Nicolas Dufresne
2023-08-10 13:44 ` Paul Kocialkowski
2023-08-10 14:34 ` Nicolas Dufresne
2023-08-11 20:08 ` Paul Kocialkowski
2023-08-21 15:13 ` Nicolas Dufresne
2023-08-22 8:30 ` Hsia-Jun Li
2023-08-22 20:31 ` Nicolas Dufresne
2023-08-23 3:04 ` Hsia-Jun Li
2023-08-30 15:10 ` Nicolas Dufresne
2023-08-30 16:51 ` Randy Li
2023-08-30 15:18 ` Nicolas Dufresne
2023-08-31 9:32 ` Hsia-Jun Li
2023-08-23 8:05 ` Paul Kocialkowski
2023-11-15 13:19 ` Paul Kocialkowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2d75cf6-2e57-65ab-ebf1-caaa17f479e0@synaptics.com \
--to=randy.li@synaptics.com \
--cc=andrzej.p@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jernej.skrabec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=nicolas.dufresne@collabora.com \
--cc=paul.kocialkowski@bootlin.com \
--cc=sakari.ailus@iki.fi \
--cc=samuel@sholland.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).