From: Nicolas Dufresne <nicolas@ndufresne.ca> To: Ezequiel Garcia <ezequiel@collabora.com>, Tomasz Figa <tfiga@chromium.org> Cc: Linux Media Mailing List <linux-media@vger.kernel.org>, kernel@collabora.com, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>, Philipp Zabel <p.zabel@pengutronix.de>, Boris Brezillon <boris.brezillon@collabora.com>, Chris Healy <cphealy@gmail.com> Subject: Re: [PATCH 0/4] Enable Hantro G1 post-processor Date: Wed, 11 Sep 2019 15:49:38 -0400 [thread overview] Message-ID: <c7b62640ae0e57a9da0c6c5245b5454af08ad2a0.camel@ndufresne.ca> (raw) In-Reply-To: <6e493142690d48ee7e65c1cb2a4d6aec1e3b671b.camel@collabora.com> [-- Attachment #1: Type: text/plain, Size: 2330 bytes --] Le mercredi 11 septembre 2019 à 09:27 +0100, Ezequiel Garcia a écrit : > On Mon, 2019-09-09 at 16:07 +0900, Tomasz Figa wrote: > > Hi Ezequiel, > > > > On Wed, Sep 4, 2019 at 3:17 AM Ezequiel Garcia <ezequiel@collabora.com> wrote: > > > Hi all, > > > > > > This series enables the post-processor support available > > > on the Hantro G1 VPU. The post-processor block can be > > > pipelined with the decoder hardware, allowing to perform > > > operations such as color conversion, scaling, rotation, > > > cropping, among others. > > > > > > The decoder hardware needs its own set of NV12 buffers > > > (the native decoder format), and the post-processor is the > > > owner of the CAPTURE buffers. This allows the application > > > get processed (scaled, converted, etc) buffers, completely > > > transparently. > > > > > > This feature is implemented by exposing other CAPTURE pixel > > > formats to the application (ENUM_FMT). When the application > > > sets a pixel format other than NV12, the driver will enable > > > and use the post-processor transparently. > > > > I'll try to review the series a bit later, but a general comment here > > is that the userspace wouldn't have a way to distinguish between the > > native and post-processed formats. I'm pretty much sure that > > post-processing at least imposes some power penalty, so it would be > > good if the userspace could avoid it if unnecessary. > > > > Hm, that's true, good catch. > > So, it would be desirable to retain the current behavior of allowing > the application to just set a different pixel format and get > a post-processed frame, transparently. > > But at the same time, it would be nice if the application is somehow > aware of the post-processing happening. Maybe we can expose a more > accurate media controller topology, have applications enable > the post-processing pipeline explicitly. How it works on the stateful side is that userspace set the encoding type (the codec), then passes a header (in our case, there will be parsed structures replacing this) first. The driver then configure capture format, giving a hint of the "default" or "native" format. This may or may not be sufficient, but it does work in giving userspace a hint. > > Thanks for the feedback, > Ezequiel > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 195 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Dufresne <nicolas-dDhyB4GVkw9AFePFGvp55w@public.gmane.org> To: Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> Cc: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>, Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>, "open list:ARM/Rockchip SoC..." <linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, Chris Healy <cphealy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Linux Media Mailing List <linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH 0/4] Enable Hantro G1 post-processor Date: Wed, 11 Sep 2019 15:49:38 -0400 [thread overview] Message-ID: <c7b62640ae0e57a9da0c6c5245b5454af08ad2a0.camel@ndufresne.ca> (raw) In-Reply-To: <6e493142690d48ee7e65c1cb2a4d6aec1e3b671b.camel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> [-- Attachment #1.1: Type: text/plain, Size: 2356 bytes --] Le mercredi 11 septembre 2019 à 09:27 +0100, Ezequiel Garcia a écrit : > On Mon, 2019-09-09 at 16:07 +0900, Tomasz Figa wrote: > > Hi Ezequiel, > > > > On Wed, Sep 4, 2019 at 3:17 AM Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote: > > > Hi all, > > > > > > This series enables the post-processor support available > > > on the Hantro G1 VPU. The post-processor block can be > > > pipelined with the decoder hardware, allowing to perform > > > operations such as color conversion, scaling, rotation, > > > cropping, among others. > > > > > > The decoder hardware needs its own set of NV12 buffers > > > (the native decoder format), and the post-processor is the > > > owner of the CAPTURE buffers. This allows the application > > > get processed (scaled, converted, etc) buffers, completely > > > transparently. > > > > > > This feature is implemented by exposing other CAPTURE pixel > > > formats to the application (ENUM_FMT). When the application > > > sets a pixel format other than NV12, the driver will enable > > > and use the post-processor transparently. > > > > I'll try to review the series a bit later, but a general comment here > > is that the userspace wouldn't have a way to distinguish between the > > native and post-processed formats. I'm pretty much sure that > > post-processing at least imposes some power penalty, so it would be > > good if the userspace could avoid it if unnecessary. > > > > Hm, that's true, good catch. > > So, it would be desirable to retain the current behavior of allowing > the application to just set a different pixel format and get > a post-processed frame, transparently. > > But at the same time, it would be nice if the application is somehow > aware of the post-processing happening. Maybe we can expose a more > accurate media controller topology, have applications enable > the post-processing pipeline explicitly. How it works on the stateful side is that userspace set the encoding type (the codec), then passes a header (in our case, there will be parsed structures replacing this) first. The driver then configure capture format, giving a hint of the "default" or "native" format. This may or may not be sufficient, but it does work in giving userspace a hint. > > Thanks for the feedback, > Ezequiel > [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 195 bytes --] [-- Attachment #2: Type: text/plain, Size: 200 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2019-09-11 19:49 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-03 18:17 [PATCH 0/4] Enable Hantro G1 post-processor Ezequiel Garcia 2019-09-03 18:17 ` Ezequiel Garcia 2019-09-03 18:17 ` [PATCH 1/4] media: hantro: Simplify macroblock macros Ezequiel Garcia 2019-09-03 18:17 ` Ezequiel Garcia 2019-09-04 10:50 ` Philipp Zabel 2019-09-04 10:50 ` Philipp Zabel 2019-09-03 18:17 ` [PATCH 2/4] media: hantro: Simplify buffer helpers Ezequiel Garcia 2019-09-03 18:17 ` Ezequiel Garcia 2019-09-04 10:50 ` Philipp Zabel 2019-09-04 10:50 ` Philipp Zabel 2019-09-03 18:17 ` [PATCH 3/4] media: hantro: Add helper for the H264 motion vectors allocation Ezequiel Garcia 2019-09-03 18:17 ` Ezequiel Garcia 2019-09-04 10:17 ` Philipp Zabel 2019-09-04 10:17 ` Philipp Zabel 2019-09-04 12:50 ` Ezequiel Garcia 2019-09-04 12:50 ` Ezequiel Garcia 2019-09-03 18:17 ` [PATCH 4/4] media: hantro: Support color conversion via post-processing Ezequiel Garcia 2019-09-03 18:17 ` Ezequiel Garcia 2019-09-09 11:03 ` Hans Verkuil 2019-09-09 11:03 ` Hans Verkuil 2019-09-11 8:34 ` Ezequiel Garcia 2019-09-11 8:34 ` Ezequiel Garcia 2019-09-09 7:07 ` [PATCH 0/4] Enable Hantro G1 post-processor Tomasz Figa 2019-09-09 7:07 ` Tomasz Figa 2019-09-11 8:27 ` Ezequiel Garcia 2019-09-11 8:27 ` Ezequiel Garcia 2019-09-11 19:48 ` Nicolas Dufresne 2019-09-11 19:48 ` Nicolas Dufresne 2019-09-11 19:49 ` Nicolas Dufresne [this message] 2019-09-11 19:49 ` Nicolas Dufresne 2019-09-12 5:52 ` Tomasz Figa 2019-09-12 5:52 ` Tomasz Figa 2019-09-12 11:35 ` Ezequiel Garcia 2019-09-12 11:35 ` Ezequiel Garcia 2019-09-16 18:18 ` Helen Koike 2019-09-16 18:18 ` Helen Koike
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=c7b62640ae0e57a9da0c6c5245b5454af08ad2a0.camel@ndufresne.ca \ --to=nicolas@ndufresne.ca \ --cc=boris.brezillon@collabora.com \ --cc=cphealy@gmail.com \ --cc=ezequiel@collabora.com \ --cc=heiko@sntech.de \ --cc=jonas@kwiboo.se \ --cc=kernel@collabora.com \ --cc=linux-media@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=p.zabel@pengutronix.de \ --cc=tfiga@chromium.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.