From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>,
mchehab@kernel.org, ezequiel@vanguardiasur.com.ar,
p.zabel@pengutronix.de, gregkh@linuxfoundation.org,
mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org,
samuel@sholland.org, andrzej.p@collabora.com,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-staging@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, kernel@collabora.com
Subject: Re: [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control
Date: Wed, 01 Jun 2022 13:07:54 -0400 [thread overview]
Message-ID: <763308daa3304ef3cf011b4ca7b9c5c006627c90.camel@collabora.com> (raw)
In-Reply-To: <11988268.O9o76ZdvQC@jernej-laptop>
Le mercredi 01 juin 2022 à 18:35 +0200, Jernej Škrabec a écrit :
> > I believe its defined following "Table A.8 – General tier and level limits".
> > With the assumption there will never be a level 7 (which I think is fair).
> > If anyone saw other reasons for this limit, let me know.
> >
> > This is a worse case scenario, this is quite unlikely in practice, so while
> > performance might be a disaster if your craft a stream for that case, I
> > don't think it will ever happen in real life.
>
> But do we really need to cover worst case scenario? In theory, one driver can
> set limit to (for example) max 100 slices and if there is a frame with 600
> slices, userspace app would submit 6 decode requests. Basically the same way
> it's done today. While not as performant, it would be good compromise between
> resources and speed.
The limit here is to prevent userland from tricking the kernel into doing very
big allocation. But with dynamic array, you'll allocate just the right amount.
Nicolas
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>,
mchehab@kernel.org, ezequiel@vanguardiasur.com.ar,
p.zabel@pengutronix.de, gregkh@linuxfoundation.org,
mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org,
samuel@sholland.org, andrzej.p@collabora.com,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-staging@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, kernel@collabora.com
Subject: Re: [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control
Date: Wed, 01 Jun 2022 13:07:54 -0400 [thread overview]
Message-ID: <763308daa3304ef3cf011b4ca7b9c5c006627c90.camel@collabora.com> (raw)
In-Reply-To: <11988268.O9o76ZdvQC@jernej-laptop>
Le mercredi 01 juin 2022 à 18:35 +0200, Jernej Škrabec a écrit :
> > I believe its defined following "Table A.8 – General tier and level limits".
> > With the assumption there will never be a level 7 (which I think is fair).
> > If anyone saw other reasons for this limit, let me know.
> >
> > This is a worse case scenario, this is quite unlikely in practice, so while
> > performance might be a disaster if your craft a stream for that case, I
> > don't think it will ever happen in real life.
>
> But do we really need to cover worst case scenario? In theory, one driver can
> set limit to (for example) max 100 slices and if there is a frame with 600
> slices, userspace app would submit 6 decode requests. Basically the same way
> it's done today. While not as performant, it would be good compromise between
> resources and speed.
The limit here is to prevent userland from tricking the kernel into doing very
big allocation. But with dynamic array, you'll allocate just the right amount.
Nicolas
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>,
mchehab@kernel.org, ezequiel@vanguardiasur.com.ar,
p.zabel@pengutronix.de, gregkh@linuxfoundation.org,
mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org,
samuel@sholland.org, andrzej.p@collabora.com,
"Hans Verkuil" <hverkuil@xs4all.nl>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org,
linux-staging@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, kernel@collabora.com
Subject: Re: [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control
Date: Wed, 01 Jun 2022 13:07:54 -0400 [thread overview]
Message-ID: <763308daa3304ef3cf011b4ca7b9c5c006627c90.camel@collabora.com> (raw)
In-Reply-To: <11988268.O9o76ZdvQC@jernej-laptop>
Le mercredi 01 juin 2022 à 18:35 +0200, Jernej Škrabec a écrit :
> > I believe its defined following "Table A.8 – General tier and level limits".
> > With the assumption there will never be a level 7 (which I think is fair).
> > If anyone saw other reasons for this limit, let me know.
> >
> > This is a worse case scenario, this is quite unlikely in practice, so while
> > performance might be a disaster if your craft a stream for that case, I
> > don't think it will ever happen in real life.
>
> But do we really need to cover worst case scenario? In theory, one driver can
> set limit to (for example) max 100 slices and if there is a frame with 600
> slices, userspace app would submit 6 decode requests. Basically the same way
> it's done today. While not as performant, it would be good compromise between
> resources and speed.
The limit here is to prevent userland from tricking the kernel into doing very
big allocation. But with dynamic array, you'll allocate just the right amount.
Nicolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-01 17:08 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 14:31 [PATCH v6 00/17] Move HEVC stateless controls out of staging Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 01/17] videodev2.h: add V4L2_CTRL_FLAG_DYNAMIC_ARRAY Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 02/17] v4l2-ctrls: add support for dynamically allocated arrays Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 03/17] vivid: add dynamic array test control Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 04/17] media: uapi: HEVC: Add missing fields in HEVC controls Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 05/17] media: uapi: HEVC: Rename HEVC stateless controls with STATELESS prefix Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 06/17] media: uapi: HEVC: Change pic_order_cnt definition in v4l2_hevc_dpb_entry Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 07/17] media: uapi: HEVC: Add SEI pic struct flags Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 08/17] media: uapi: HEVC: Add documentation to uAPI structure Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 09/17] media: uapi: HEVC: Define V4L2_CID_STATELESS_HEVC_SLICE_PARAMS as a dynamic array Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-29 9:19 ` Jernej Škrabec
2022-05-29 9:19 ` Jernej Škrabec
2022-05-29 9:19 ` Jernej Škrabec
2022-06-01 15:43 ` Jernej Škrabec
2022-06-01 15:43 ` Jernej Škrabec
2022-06-01 15:43 ` Jernej Škrabec
2022-06-01 16:02 ` Benjamin Gaignard
2022-06-01 16:02 ` Benjamin Gaignard
2022-06-01 16:02 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 10/17] media: uapi: Move parsed HEVC pixel format out of staging Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 11/17] media: uapi: Add V4L2_CID_STATELESS_HEVC_ENTRY_POINT_OFFSETS control Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-29 6:40 ` Jernej Škrabec
2022-05-29 6:40 ` Jernej Škrabec
2022-05-29 6:40 ` Jernej Škrabec
2022-05-30 9:18 ` Hans Verkuil
2022-05-30 9:18 ` Hans Verkuil
2022-05-30 9:18 ` Hans Verkuil
2022-05-30 13:49 ` Hans Verkuil
2022-05-30 13:49 ` Hans Verkuil
2022-05-30 13:49 ` Hans Verkuil
2022-05-30 21:24 ` Jernej Škrabec
2022-05-30 21:24 ` Jernej Škrabec
2022-05-30 21:24 ` Jernej Škrabec
2022-05-31 6:58 ` Benjamin Gaignard
2022-05-31 6:58 ` Benjamin Gaignard
2022-05-31 6:58 ` Benjamin Gaignard
2022-05-31 18:20 ` Jernej Škrabec
2022-05-31 18:20 ` Jernej Škrabec
2022-05-31 18:20 ` Jernej Škrabec
2022-06-01 16:20 ` Nicolas Dufresne
2022-06-01 16:20 ` Nicolas Dufresne
2022-06-01 16:20 ` Nicolas Dufresne
2022-06-01 16:35 ` Jernej Škrabec
2022-06-01 16:35 ` Jernej Škrabec
2022-06-01 16:35 ` Jernej Škrabec
2022-06-01 17:07 ` Nicolas Dufresne [this message]
2022-06-01 17:07 ` Nicolas Dufresne
2022-06-01 17:07 ` Nicolas Dufresne
2022-06-10 14:08 ` John Cox
2022-06-10 14:08 ` John Cox
2022-06-10 14:08 ` John Cox
2022-05-27 14:31 ` [PATCH v6 12/17] media: uapi: Move the HEVC stateless control type out of staging Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 13/17] media: controls: Log HEVC stateless control in .std_log Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 14/17] media: hantro: Stop using Hantro dedicated control Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 15/17] media: uapi: HEVC: fix padding in v4l2 control structures Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` [PATCH v6 16/17] media: uapi: Change data_bit_offset definition Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-05-29 6:45 ` Jernej Škrabec
2022-05-29 6:45 ` Jernej Škrabec
2022-05-29 6:45 ` Jernej Škrabec
2022-06-01 16:17 ` Jernej Škrabec
2022-06-01 16:17 ` Jernej Škrabec
2022-06-01 16:17 ` Jernej Škrabec
2022-06-01 16:33 ` Benjamin Gaignard
2022-06-01 16:33 ` Benjamin Gaignard
2022-06-01 16:33 ` Benjamin Gaignard
2022-06-12 20:40 ` Jernej Škrabec
2022-06-12 20:40 ` Jernej Škrabec
2022-06-12 20:40 ` Jernej Škrabec
2022-06-13 18:17 ` Jernej Škrabec
2022-06-13 18:17 ` Jernej Škrabec
2022-06-13 18:17 ` Jernej Škrabec
2022-05-27 14:31 ` [PATCH v6 17/17] media: uapi: move HEVC stateless controls out of staging Benjamin Gaignard
2022-05-27 14:31 ` Benjamin Gaignard
2022-06-10 14:00 ` [PATCH v6 00/17] Move " John Cox
2022-06-10 14:00 ` John Cox
2022-06-10 14:00 ` John Cox
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=763308daa3304ef3cf011b4ca7b9c5c006627c90.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=andrzej.p@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=gregkh@linuxfoundation.org \
--cc=hverkuil@xs4all.nl \
--cc=jernej.skrabec@gmail.com \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-sunxi@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=mripard@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=samuel@sholland.org \
--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 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.