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 <ezequ...@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. Thanks for the feedback, Ezequiel
