linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: linux-sunxi@googlegroups.com, linux-media@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [linux-sunxi] Re: [PATCH 1/3] media: cedrus: Properly signal size in mode register
Date: Sat, 9 Nov 2019 13:56:57 +0100	[thread overview]
Message-ID: <20191109125657.GB845368@aptenodytes> (raw)
In-Reply-To: <jwv1ruj7on7.fsf-monnier+gmane.comp.hardware.netbook.arm.sunxi@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

Hi Stefan,

On Thu 07 Nov 19, 09:24, Stefan Monnier wrote:
> > Do you know if we have a way to report some estimation of the maximum supported
> > fps to userspace? It would be useful to let userspace decide whether it's a
> > better fit than software decoding.
> 
> Even if the fps ends up too low for the player's taste, I can't imagine
> why software decoding would be preferable: it seems it could be only
> even (substantially) slower.  Or are there speed-up options in software
> decoding not available in hardware decoding (such as playing only every
> N'th frame, maybe?).

This may be true for the Allwinner case as we know it today but not true in
general. It could happen that the CPU is perfectly able to decode as fast as or
faster than the hardware implementation, but userspace would still try to use
hardware video decoding when it can provide good enough performance so that the
CPU can do other things in the meantime.

Having a good idea of the expected performance is important for userspace to
make this kind of policy decision.

This is kind of a common misconception that hardware offloading always implies
a performance improvment. In our cases where the CPU is a bottleneck, it is
more often true than not, but this is by far not true in general.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2019-11-09 12:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-26  7:49 [PATCH 0/3] media: cedrus: Add support for 4k videos Jernej Skrabec
2019-10-26  7:49 ` [PATCH 1/3] media: cedrus: Properly signal size in mode register Jernej Skrabec
2019-11-04 10:02   ` Paul Kocialkowski
2019-11-04 16:33     ` Jernej Škrabec
2019-11-05  8:10       ` Paul Kocialkowski
2019-11-06 17:41         ` Jernej Škrabec
     [not found]         ` <jwv1ruj7on7.fsf-monnier+gmane.comp.hardware.netbook.arm.sunxi@gnu.org>
2019-11-09 12:56           ` Paul Kocialkowski [this message]
2019-10-26  7:49 ` [PATCH 2/3] media: cedrus: Fix H264 4k support Jernej Skrabec
2019-11-04 10:13   ` Paul Kocialkowski
2019-11-04 16:53     ` Jernej Škrabec
2019-11-05  8:07       ` Paul Kocialkowski
2019-10-26  7:49 ` [PATCH 3/3] media: cedrus: Increase maximum supported size Jernej Skrabec
2019-11-04 10:14   ` 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=20191109125657.GB845368@aptenodytes \
    --to=paul.kocialkowski@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=monnier@iro.umontreal.ca \
    /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).