All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Brian Starkey <Brian.Starkey@arm.com>
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 19:25:02 +0200	[thread overview]
Message-ID: <CAKMK7uHEWQiXYE7RE7TffHEHMys=LTYcNeK+iAX3qiS-c2PNjQ@mail.gmail.com> (raw)
In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain>

On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey <Brian.Starkey@arm.com> wrote:
>
> Hi,
>
> On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > Hi Brian,
> >
> > On 11/10/2019 10:41, Brian Starkey wrote:

> > > Are you sure the GPU supports other orders? I think any Arm driver
> > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888>
> > > I'm not convinced the GPU HW actually supports any other order, but
> > > it's all rather confusing with texture swizzling. What I can tell you
> > > for sure is that it _does_ support BGR order (in DRM naming
> > > convention).
> >
> > Well, since the Bifrost Mali blobs are closed-source and delivered
> > by licensees, it's hard to define what is supported from a closed
> > GPU HW, closed SW implementation to a closed pixel format implementation.
> >
>
> I hear you. IMO the only way to make any of this clear is to publish
> reference data and tests which make sure implementations match each
> other. It's something I'm trying to make happen.

*cough* igt test with crc/writeback validation *cough*

And you don't even need anything that actually compresses. All you
need is the minimal enough AFBC knowledge to set up the metadata that
everything is uncompressed. We're doing that for our intel compression
formats already, and it works great in making sure that we have
end-to-end agreement on all the bits and ordering and everything. Ofc
it doesn't validate the decoder, but that's not really igts job.
Should be possible to convince ARM to release that (as open source, in
igt), since it would be fairly valuable for the entire ecosystem here
...
-Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

_______________________________________________
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 Vetter <daniel@ffwll.ch>
To: Brian Starkey <Brian.Starkey@arm.com>
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 19:25:02 +0200	[thread overview]
Message-ID: <CAKMK7uHEWQiXYE7RE7TffHEHMys=LTYcNeK+iAX3qiS-c2PNjQ@mail.gmail.com> (raw)
In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain>

On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey <Brian.Starkey@arm.com> wrote:
>
> Hi,
>
> On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > Hi Brian,
> >
> > On 11/10/2019 10:41, Brian Starkey wrote:

> > > Are you sure the GPU supports other orders? I think any Arm driver
> > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888>
> > > I'm not convinced the GPU HW actually supports any other order, but
> > > it's all rather confusing with texture swizzling. What I can tell you
> > > for sure is that it _does_ support BGR order (in DRM naming
> > > convention).
> >
> > Well, since the Bifrost Mali blobs are closed-source and delivered
> > by licensees, it's hard to define what is supported from a closed
> > GPU HW, closed SW implementation to a closed pixel format implementation.
> >
>
> I hear you. IMO the only way to make any of this clear is to publish
> reference data and tests which make sure implementations match each
> other. It's something I'm trying to make happen.

*cough* igt test with crc/writeback validation *cough*

And you don't even need anything that actually compresses. All you
need is the minimal enough AFBC knowledge to set up the metadata that
everything is uncompressed. We're doing that for our intel compression
formats already, and it works great in making sure that we have
end-to-end agreement on all the bits and ordering and everything. Ofc
it doesn't validate the decoder, but that's not really igts job.
Should be possible to convince ARM to release that (as open source, in
igt), since it would be fairly valuable for the entire ecosystem here
...
-Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
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 Vetter <daniel@ffwll.ch>
To: Brian Starkey <Brian.Starkey@arm.com>
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 19:25:02 +0200	[thread overview]
Message-ID: <CAKMK7uHEWQiXYE7RE7TffHEHMys=LTYcNeK+iAX3qiS-c2PNjQ@mail.gmail.com> (raw)
In-Reply-To: <20191011105559.clttghy52wfdmb34@DESKTOP-E1NTVVP.localdomain>

On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey <Brian.Starkey@arm.com> wrote:
>
> Hi,
>
> On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote:
> > Hi Brian,
> >
> > On 11/10/2019 10:41, Brian Starkey wrote:

> > > Are you sure the GPU supports other orders? I think any Arm driver
> > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888>
> > > I'm not convinced the GPU HW actually supports any other order, but
> > > it's all rather confusing with texture swizzling. What I can tell you
> > > for sure is that it _does_ support BGR order (in DRM naming
> > > convention).
> >
> > Well, since the Bifrost Mali blobs are closed-source and delivered
> > by licensees, it's hard to define what is supported from a closed
> > GPU HW, closed SW implementation to a closed pixel format implementation.
> >
>
> I hear you. IMO the only way to make any of this clear is to publish
> reference data and tests which make sure implementations match each
> other. It's something I'm trying to make happen.

*cough* igt test with crc/writeback validation *cough*

And you don't even need anything that actually compresses. All you
need is the minimal enough AFBC knowledge to set up the metadata that
everything is uncompressed. We're doing that for our intel compression
formats already, and it works great in making sure that we have
end-to-end agreement on all the bits and ordering and everything. Ofc
it doesn't validate the decoder, but that's not really igts job.
Should be possible to convince ARM to release that (as open source, in
igt), since it would be fairly valuable for the entire ecosystem here
...
-Daniel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  parent reply	other threads:[~2019-10-11 17:25 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
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 [this message]
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='CAKMK7uHEWQiXYE7RE7TffHEHMys=LTYcNeK+iAX3qiS-c2PNjQ@mail.gmail.com' \
    --to=daniel@ffwll.ch \
    --cc=Ayan.Halder@arm.com \
    --cc=Brian.Starkey@arm.com \
    --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.