All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simona Vetter <simona.vetter@ffwll.ch>
To: "Marek Olšák" <maraeo@gmail.com>
Cc: "Brian Starkey" <brian.starkey@arm.com>,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	"Michel Dänzer" <michel.daenzer@mailbox.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"amd-gfx mailing list" <amd-gfx@lists.freedesktop.org>,
	"ML Mesa-dev" <mesa-dev@lists.freedesktop.org>,
	nd@arm.com
Subject: Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment
Date: Fri, 20 Dec 2024 16:27:18 +0100	[thread overview]
Message-ID: <Z2WM1pbVvNKdj6QJ@phenom.ffwll.local> (raw)
In-Reply-To: <CAAxE2A77DVSWM0vOZcBSmM+1sbt2kOdCC7SRDMRpeBPsW_J2Vg@mail.gmail.com>

On Fri, Dec 20, 2024 at 09:24:59AM -0500, Marek Olšák wrote:
> >
> >  * Modifiers must uniquely encode buffer layout. In other words, a buffer
> > must
> >  * match only a single modifier.
> >
> 
> That sentence is misleading and impossible to meet. Specifications are
> sometimes changed to reflect the overwhelming reality. Multiple modifiers
> can represent identical layouts - they already do between vendors, between
> generations of the same vendor, and accidentally even between chips of the
> same generation. Modifiers have already become 64-bit structures of
> bitfields with currently 2^16 possible modifiers for some vendors, and
> possibly exceeding 100k for all vendors combined. Encoding all linear
> constraints into the 64 bits is one option. It needs more thought, but
> encoding at least some constraints in the modifier is not totally off the
> table.

Yeah uniqueness is not required, we just try to avoid it since it causes
some pain. Worst case all drivers that care about working sharing just
need to make sure they advertise all overlapping variants they support.

> The semi-functional LINEAR modifier needs to go. The idea of modifiers is
> that nobody should have to expose one that is unsupported to keep things
> working for a subset of apps. If the LINEAR modifier is a requirement
> everywhere because of apps, and even drivers that can't support it must
> expose it, that's a problem. It causes GBM/EGL to fail to import a DMABUF
> for a random reason and it can't be prevented without, say, looking at PCI
> IDs. If that happened for any other API, it would be considered unusable.
> We can either fix it (by replacing/deprecating/removing LINEAR) or abandon
> modifiers and replace them with something that works.

I think Daniel's forward compatibility plan is more solid than trying to
deprecate LINEAR itself, that seems like too much an uphill battle to me.
-Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2024-12-20 15:27 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-15 20:53 [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment Marek Olšák
2024-12-15 20:54 ` Marek Olšák
2024-12-15 23:22   ` Joshua Ashton
2024-12-15 23:57     ` Marek Olšák
2024-12-16  2:08       ` Joshua Ashton
2024-12-16  5:40         ` Marek Olšák
2024-12-16  9:28           ` Dmitry Baryshkov
2024-12-16 21:49             ` Marek Olšák
2024-12-16  9:27 ` Michel Dänzer
2024-12-16 10:46   ` Lucas Stach
2024-12-16 14:53     ` Simona Vetter
2024-12-16 21:58       ` Marek Olšák
2024-12-18 10:21         ` Simona Vetter
2024-12-16 21:54     ` Marek Olšák
2024-12-17  9:59       ` Michel Dänzer
2024-12-16 21:29   ` Marek Olšák
2024-12-17  9:14     ` Michel Dänzer
2024-12-17  9:14 ` Brian Starkey
2024-12-17 10:13   ` Michel Dänzer
2024-12-17 11:03     ` Brian Starkey
2024-12-18  9:44       ` Michel Dänzer
2024-12-18 10:24         ` Simona Vetter
2024-12-18 10:32           ` Brian Starkey
2024-12-19  2:53             ` Marek Olšák
2024-12-19  9:09               ` Daniel Stone
2024-12-19 10:32               ` Brian Starkey
2024-12-20  0:33                 ` Marek Olšák
2024-12-20 11:30                   ` Brian Starkey
2024-12-20 14:24                     ` Marek Olšák
2024-12-20 15:27                       ` Simona Vetter [this message]
2024-12-19  9:02             ` Daniel Stone
2024-12-19 16:09               ` Michel Dänzer
2024-12-20 15:24                 ` Simona Vetter
2024-12-25  7:34                   ` Marek Olšák
2024-12-19 18:03               ` Simona Vetter
2025-01-10 21:23                 ` James Jones
2025-01-14  9:38                   ` Marek Olšák
2025-01-14 17:55                     ` James Jones
2025-01-15  3:49                       ` Marek Olšák
2025-01-14 17:58                     ` Daniel Stone
2025-01-15  4:05                       ` Marek Olšák
2025-01-15 12:20                         ` Daniel Stone
2025-01-17 14:18                           ` Simona Vetter
2025-01-18  2:37                             ` Marek Olšák
2025-01-20  7:58                               ` Thomas Zimmermann
2025-01-20 18:41                                 ` Simona Vetter
2025-01-21 19:21                                   ` Marek Olšák
2025-01-22 10:47                                     ` Simona Vetter
2025-01-20 21:31                                 ` Laurent Pinchart
2025-01-21  9:02                                 ` Philipp Zabel
2025-01-14 18:33                     ` Faith Ekstrand
2025-01-15  4:27                       ` Marek Olšák
2025-01-15  8:37                       ` Simona Vetter
2025-01-20 22:00                   ` Laurent Pinchart
2025-01-21 22:40                     ` James Jones
2025-01-20 21:48     ` Laurent Pinchart
2025-01-14 13:46 ` Thomas Zimmermann
2025-01-14 13:50   ` Thomas Zimmermann

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=Z2WM1pbVvNKdj6QJ@phenom.ffwll.local \
    --to=simona.vetter@ffwll.ch \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=brian.starkey@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maraeo@gmail.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=michel.daenzer@mailbox.org \
    --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.