From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: nd <nd@arm.com>, Neil Armstrong <narmstrong@baylibre.com>,
"khilman@baylibre.com" <khilman@baylibre.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-amlogic@lists.infradead.org"
<linux-amlogic@lists.infradead.org>,
Ayan Halder <Ayan.Halder@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Date: Fri, 11 Oct 2019 08:56:26 +0100 [thread overview]
Message-ID: <CAPj87rOMupGnq5B=eWjcu0-Bkj_HmfLDR3Aqk1VDCXg8TwYP0w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uE2p_VbJB5PfS1DJ5AzOm60p22c+YOJ18FtD4_ec61LwQ@mail.gmail.com>
Hi,
On Fri, 11 Oct 2019 at 08:46, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder <Ayan.Halder@arm.com> wrote:
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> > > Sorry I don't understand, you ask me to limit AFBC to ABGR8888 ?
> >
> > Apologies for the confusion, as per the link, the formats which are
> > suggested with AFBC_FORMAT_MOD_YTR are the BGR/ABGR formats (as
> > listed in the 'AFBC formats' table)
> >
> > Thus, any other permutation of the components might make it incompatible
> > with some other AFBC producers/consumers.
>
> Uh, that's not how this is supposed to be used. Drivers are meant to
> expose _everything_ they support (bonus if you roughly sort it in
> preference order). Userspace then computes the intersection of
> modifiers/formats supported by all devices it needs to share a buffer
> with. Allowing that was the entire point of modifiers, if we
> artificially limit to the common denominator we're back "only linear
> works everywhere".
Correct.
A lot of userspace will select for format first, then find a modifier
which can be used with that format. If userspace has specific
knowledge of AFBC and decides that it prefers to use AFBC so will seek
out an alpha format - and make sure everyone fills the channel solid -
then that's fine. But that's putting the cart before the horse.
Not exposing XRGB8888 on the primary plane will break a lot of
userspace, so in this case AFBC would just never really be used.
Cheers,
Daniel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: nd <nd@arm.com>, Neil Armstrong <narmstrong@baylibre.com>,
"khilman@baylibre.com" <khilman@baylibre.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-amlogic@lists.infradead.org"
<linux-amlogic@lists.infradead.org>,
Ayan Halder <Ayan.Halder@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Date: Fri, 11 Oct 2019 08:56:26 +0100 [thread overview]
Message-ID: <CAPj87rOMupGnq5B=eWjcu0-Bkj_HmfLDR3Aqk1VDCXg8TwYP0w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uE2p_VbJB5PfS1DJ5AzOm60p22c+YOJ18FtD4_ec61LwQ@mail.gmail.com>
Hi,
On Fri, 11 Oct 2019 at 08:46, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder <Ayan.Halder@arm.com> wrote:
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> > > Sorry I don't understand, you ask me to limit AFBC to ABGR8888 ?
> >
> > Apologies for the confusion, as per the link, the formats which are
> > suggested with AFBC_FORMAT_MOD_YTR are the BGR/ABGR formats (as
> > listed in the 'AFBC formats' table)
> >
> > Thus, any other permutation of the components might make it incompatible
> > with some other AFBC producers/consumers.
>
> Uh, that's not how this is supposed to be used. Drivers are meant to
> expose _everything_ they support (bonus if you roughly sort it in
> preference order). Userspace then computes the intersection of
> modifiers/formats supported by all devices it needs to share a buffer
> with. Allowing that was the entire point of modifiers, if we
> artificially limit to the common denominator we're back "only linear
> works everywhere".
Correct.
A lot of userspace will select for format first, then find a modifier
which can be used with that format. If userspace has specific
knowledge of AFBC and decides that it prefers to use AFBC so will seek
out an alpha format - and make sure everyone fills the channel solid -
then that's fine. But that's putting the cart before the horse.
Not exposing XRGB8888 on the primary plane will break a lot of
userspace, so in this case AFBC would just never really be used.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Stone <daniel@fooishbar.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: nd <nd@arm.com>, Neil Armstrong <narmstrong@baylibre.com>,
"khilman@baylibre.com" <khilman@baylibre.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-amlogic@lists.infradead.org"
<linux-amlogic@lists.infradead.org>,
Ayan Halder <Ayan.Halder@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane
Date: Fri, 11 Oct 2019 08:56:26 +0100 [thread overview]
Message-ID: <CAPj87rOMupGnq5B=eWjcu0-Bkj_HmfLDR3Aqk1VDCXg8TwYP0w@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uE2p_VbJB5PfS1DJ5AzOm60p22c+YOJ18FtD4_ec61LwQ@mail.gmail.com>
Hi,
On Fri, 11 Oct 2019 at 08:46, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Oct 10, 2019 at 7:32 PM Ayan Halder <Ayan.Halder@arm.com> wrote:
> > On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote:
> > > Sorry I don't understand, you ask me to limit AFBC to ABGR8888 ?
> >
> > Apologies for the confusion, as per the link, the formats which are
> > suggested with AFBC_FORMAT_MOD_YTR are the BGR/ABGR formats (as
> > listed in the 'AFBC formats' table)
> >
> > Thus, any other permutation of the components might make it incompatible
> > with some other AFBC producers/consumers.
>
> Uh, that's not how this is supposed to be used. Drivers are meant to
> expose _everything_ they support (bonus if you roughly sort it in
> preference order). Userspace then computes the intersection of
> modifiers/formats supported by all devices it needs to share a buffer
> with. Allowing that was the entire point of modifiers, if we
> artificially limit to the common denominator we're back "only linear
> works everywhere".
Correct.
A lot of userspace will select for format first, then find a modifier
which can be used with that format. If userspace has specific
knowledge of AFBC and decides that it prefers to use AFBC so will seek
out an alpha format - and make sure everyone fills the channel solid -
then that's fine. But that's putting the cart before the horse.
Not exposing XRGB8888 on the primary plane will break a lot of
userspace, so in this case AFBC would just never really be used.
Cheers,
Daniel
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2019-10-11 7:56 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 9:25 [PATCH 0/7] drm/meson: add AFBC support Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 1/7] drm/meson: add AFBC decoder registers for GXM and G12A Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 2/7] drm/meson: store the framebuffer width for plane commit Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 3/7] drm/meson: Add AFBCD module driver Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 4/7] drm/meson: plane: add support for AFBC mode for OSD1 plane Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 13:26 ` Ayan Halder
2019-10-10 13:26 ` Ayan Halder
2019-10-10 13:26 ` Ayan Halder
2019-10-10 13:41 ` Neil Armstrong
2019-10-10 13:41 ` Neil Armstrong
2019-10-10 13:41 ` Neil Armstrong
2019-10-10 17:31 ` Ayan Halder
2019-10-10 17:31 ` Ayan Halder
2019-10-10 17:31 ` Ayan Halder
2019-10-11 7:46 ` Daniel Vetter
2019-10-11 7:46 ` Daniel Vetter
2019-10-11 7:46 ` Daniel Vetter
2019-10-11 7:56 ` Daniel Stone [this message]
2019-10-11 7:56 ` Daniel Stone
2019-10-11 7:56 ` Daniel Stone
2019-10-11 8:41 ` Brian Starkey
2019-10-11 8:41 ` Brian Starkey
2019-10-11 8:41 ` Brian Starkey
2019-10-11 9:14 ` Neil Armstrong
2019-10-11 9:14 ` Neil Armstrong
2019-10-11 9:14 ` Neil Armstrong
2019-10-11 10:56 ` Brian Starkey
2019-10-11 10:56 ` Brian Starkey
2019-10-11 10:56 ` Brian Starkey
2019-10-11 12:07 ` Neil Armstrong
2019-10-11 12:07 ` Neil Armstrong
2019-10-11 12:07 ` Neil Armstrong
2019-10-15 11:18 ` Brian Starkey
2019-10-15 11:18 ` Brian Starkey
2019-10-15 11:18 ` Brian Starkey
2019-10-15 11:46 ` Neil Armstrong
2019-10-15 11:46 ` Neil Armstrong
2019-10-15 11:46 ` Neil Armstrong
2019-10-11 17:25 ` Daniel Vetter
2019-10-11 17:25 ` Daniel Vetter
2019-10-11 17:25 ` Daniel Vetter
2019-10-14 9:11 ` Brian Starkey
2019-10-14 9:11 ` Brian Starkey
2019-10-14 9:11 ` Brian Starkey
2019-10-14 9:20 ` Daniel Vetter
2019-10-14 9:20 ` Daniel Vetter
2019-10-14 9:20 ` Daniel Vetter
2019-10-10 9:25 ` [PATCH 5/7] drm/meson: viu: add AFBC modules routing functions Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 6/7] drm/meson: hold 32 lines after vsync to give time for AFBC start Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` [PATCH 7/7] drm/meson: crtc: add OSD1 plane AFBC commit Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
2019-10-10 9:25 ` Neil Armstrong
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='CAPj87rOMupGnq5B=eWjcu0-Bkj_HmfLDR3Aqk1VDCXg8TwYP0w@mail.gmail.com' \
--to=daniel@fooishbar.org \
--cc=Ayan.Halder@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=narmstrong@baylibre.com \
--cc=nd@arm.com \
/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.