From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-amlogic@lists.infradead.org, nd <nd@arm.com>,
Brian Starkey <brian.starkey@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Date: Tue, 3 Mar 2020 17:33:32 +0200 [thread overview]
Message-ID: <20200303173332.1c6daa09@eldfell.localdomain> (raw)
In-Reply-To: <20200303152541.68ab6f3d@eldfell.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 4121 bytes --]
On Tue, 3 Mar 2020 15:25:41 +0200
Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Tue, 3 Mar 2020 12:37:16 +0100
> Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey <brian.starkey@arm.com> wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > > On Fri, 21 Feb 2020 10:08:42 +0100
> > > > Neil Armstrong <narmstrong@baylibre.com> wrote:
> > > >
...
> > > > > +/*
> > > > > + * Amlogic Video Framebuffer Compression modifiers
> > > > > + *
> > > > > + * Amlogic uses a proprietary lossless image compression protocol and format
> > > > > + * for their hardware video codec accelerators, either video decoders or
> > > > > + * video input encoders.
> > > > > + *
> > > > > + * It considerably reduces memory bandwidth while writing and reading
> > > > > + * frames in memory.
> > > > > + * Implementation details may be platform and SoC specific, and shared
> > > > > + * between the producer and the decoder on the same platform.
> > > >
> > > > Hi,
> > > >
> > > > after a lengthy IRC discussion on #dri-devel, this "may be platform and
> > > > SoC specific" is a problem.
> > > >
> > > > It can be an issue in two ways:
> > > >
> > > > - If something in the data acts like a sub-modifier, then advertising
> > > > support for one modifier does not really tell if the data layout is
> > > > supported or not.
> > > >
> > > > - If you need to know the platform and/or SoC to be able to interpret
> > > > the data, it means the modifier is ill-defined and cannot be used in
> > > > inter-machine communication (e.g. Pipewire).
> > > >
> > >
> > > Playing devil's advocate, the comment sounds similar to
> > > I915_FORMAT_MOD_{X,Y}_TILED:
> > >
> > > * This format is highly platforms specific and not useful for cross-driver
> > > * sharing. It exists since on a given platform it does uniquely identify the
> > > * layout in a simple way for i915-specific userspace.
> >
> > Yeah which we regret now. We need to now roll out a new set of
> > modifiers for at least some of the differences in these on the
> > modern-ish chips (the old crap is pretty much lost cause anyway).
> >
> > This was kinda a nasty hack to smooth things over since we have epic
> > amounts of userspace, but it's really not a great idea (and no one
> > else really has epic amounts of existing userspace that uses tiling
> > flags everywhere, this is all new code).
> > -Daniel
> >
> > > Isn't the statement that this for sharing between producer and decoder
> > > _on the same platform_ a similar clause with the same effect?
> > >
> > > What advantage is there to exposing the gory details? For Arm AFBC
> > > it's necessary because IP on the SoC can be (likely to be) from
> > > different vendors with different capabilities.
> > >
> > > If this is only for talking between Amlogic IP on the same SoC, and
> > > those devices support all the same "flavours", I don't see what is
> > > gained by making userspace care about internals.
> >
> > The trouble is if you mix&match IP cores, and one of them supports
> > flavours A, B, C and the other C, D, E. But all you have is a single
> > magic modifier for "whatever the flavour is that soc prefers". So
> > someone gets to stuff this in DT.
> >
> > Also eventually, maybe, perhaps ARM does grow up into the
> > client/server space with add-on pcie graphics, and at least for client
> > you very often end up with integrated + add-in pcie gpu. At that point
> > you really can't have magic per-soc modifiers anymore.
>
> Hi,
>
> I also heard that Pipewire will copy buffers and modifiers verbatim
> from one machine to another when streaming across network, assuming
> that the same modifier means the same thing on all machines.[Citation needed]
>
> If that is something that must not be done with DRM modifiers, then
> please contact them and document that.
Sorry, it's waypipe, not pipewire:
https://gitlab.freedesktop.org/mstoeckl/waypipe/
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2020-03-03 15:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 9:08 [PATCH 0/4] drm/meson: add support for Amlogic Video FBC Neil Armstrong
2020-02-21 9:08 ` [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
2020-03-02 16:28 ` Maxime Jourdan
2020-03-03 10:10 ` Pekka Paalanen
2020-03-03 10:53 ` Brian Starkey
2020-03-03 11:37 ` Daniel Vetter
2020-03-03 13:25 ` Pekka Paalanen
2020-03-03 15:33 ` Pekka Paalanen [this message]
2020-03-06 10:13 ` Daniel Vetter
2020-03-06 12:30 ` Pekka Paalanen
2020-03-06 14:40 ` Neil Armstrong
2020-03-06 16:17 ` Pekka Paalanen
2020-03-03 13:43 ` Brian Starkey
2020-02-21 9:08 ` [PATCH 2/4] drm/meson: add Amlogic Video FBC registers Neil Armstrong
2020-02-21 9:08 ` [PATCH 3/4] drm/meson: overlay: setup overlay for Amlogic FBC Neil Armstrong
2020-02-21 9:08 ` [PATCH 4/4] drm/meson: crtc: handle commit of Amlogic FBC frames Neil Armstrong
-- strict thread matches above, loose matches on Subject: below --
2020-02-20 16:27 [PATCH 0/4] drm/meson: add support for Amlogic Video FBC Neil Armstrong
2020-02-20 16:27 ` [PATCH 1/4] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression 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=20200303173332.1c6daa09@eldfell.localdomain \
--to=ppaalanen@gmail.com \
--cc=brian.starkey@arm.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.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 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).