From: "Marek Olšák" <maraeo@gmail.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Michel Dänzer" <michel@daenzer.net>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Jason Ekstrand" <jason@jlekstrand.net>,
"ML Mesa-dev" <mesa-dev@lists.freedesktop.org>
Subject: Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
Date: Wed, 2 Jun 2021 05:58:31 -0400 [thread overview]
Message-ID: <CAAxE2A5Hrw7oqYKttEYBdd7k6onqZc8ksak5T-Ry1oKJEZtSbw@mail.gmail.com> (raw)
In-Reply-To: <bbb990cf-008a-e4d3-93d3-a9adc2f202b7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
On Wed, Jun 2, 2021 at 5:44 AM Christian König <
ckoenig.leichtzumerken@gmail.com> wrote:
> Am 02.06.21 um 10:57 schrieb Daniel Stone:
> > Hi Christian,
> >
> > On Tue, 1 Jun 2021 at 13:51, Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >> Am 01.06.21 um 14:30 schrieb Daniel Vetter:
> >>> If you want to enable this use-case with driver magic and without the
> >>> compositor being aware of what's going on, the solution is EGLStreams.
> >>> Not sure we want to go there, but it's definitely a lot more feasible
> >>> than trying to stuff eglstreams semantics into dma-buf implicit
> >>> fencing support in a desperate attempt to not change compositors.
> >> Well not changing compositors is certainly not something I would try
> >> with this use case.
> >>
> >> Not changing compositors is more like ok we have Ubuntu 20.04 and need
> >> to support that we the newest hardware generation.
> > Serious question, have you talked to Canonical?
> >
> > I mean there's a hell of a lot of effort being expended here, but it
> > seems to all be predicated on the assumption that Ubuntu's LTS
> > HWE/backport policy is totally immutable, and that we might need to
> > make the kernel do backflips to work around that. But ... is it? Has
> > anyone actually asked them how they feel about this?
>
> This was merely an example. What I wanted to say is that we need to
> support system already deployed.
>
> In other words our customers won't accept that they need to replace the
> compositor just because they switch to a new hardware generation.
>
> > I mean, my answer to the first email is 'no, absolutely not' from the
> > technical perspective (the initial proposal totally breaks current and
> > future userspace), from a design perspective (it breaks a lot of
> > usecases which aren't single-vendor GPU+display+codec, or aren't just
> > a simple desktop), and from a sustainability perspective (cutting
> > Android adrift again isn't acceptable collateral damage to make it
> > easier to backport things to last year's Ubuntu release).
> >
> > But then again, I don't even know what I'm NAKing here ... ? The
> > original email just lists a proposal to break a ton of things, with
> > proposed replacements which aren't technically viable, and it's not
> > clear why? Can we please have some more details and some reasoning
> > behind them?
> >
> > I don't mind that userspace (compositor, protocols, clients like Mesa
> > as well as codec APIs) need to do a lot of work to support the new
> > model. I do really care though that the hard-binary-switch model works
> > fine enough for AMD but totally breaks heterogeneous systems and makes
> > it impossible for userspace to do the right thing.
>
> Well how the handling for new Android, distributions etc... is going to
> look like is a completely different story.
>
> And I completely agree with both Daniel Vetter and you that we need to
> keep this in mind when designing the compatibility with older software.
>
> For Android I'm really not sure what to do. In general Android is
> already trying to do the right thing by using explicit sync, the problem
> is that this is build around the idea that this explicit sync is
> syncfile kernel based.
>
> Either we need to change Android and come up with something that works
> with user fences as well or we somehow invent a compatibility layer for
> syncfile as well.
>
What's the issue with syncfiles that syncobjs don't suffer from?
Marek
[-- Attachment #2: Type: text/html, Size: 4364 bytes --]
next prev parent reply other threads:[~2021-06-02 9:59 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 21:51 Linux Graphics Next: Userspace submission update Marek Olšák
2021-05-28 14:41 ` Christian König
2021-05-28 22:25 ` Marek Olšák
2021-05-29 3:33 ` Marek Olšák
2021-05-31 8:25 ` Christian König
2021-06-01 9:02 ` Michel Dänzer
2021-06-01 10:21 ` Christian König
2021-06-01 10:49 ` Michel Dänzer
2021-06-01 12:10 ` [Mesa-dev] " Christian König
2021-06-01 12:30 ` Daniel Vetter
2021-06-01 12:51 ` Christian König
2021-06-01 13:01 ` Marek Olšák
2021-06-01 13:24 ` Michel Dänzer
2021-06-02 8:57 ` Daniel Stone
2021-06-02 9:34 ` Marek Olšák
2021-06-02 9:38 ` Marek Olšák
2021-06-02 18:48 ` Daniel Vetter
2021-06-02 18:52 ` Christian König
2021-06-02 19:19 ` Daniel Vetter
2021-06-04 7:00 ` Christian König
2021-06-04 8:57 ` Daniel Vetter
2021-06-04 11:27 ` Christian König
2021-06-09 13:19 ` Daniel Vetter
2021-06-09 13:58 ` Christian König
2021-06-09 18:31 ` Daniel Vetter
2021-06-10 15:59 ` Marek Olšák
2021-06-10 16:33 ` Christian König
2021-06-14 17:10 ` Marek Olšák
2021-06-14 17:13 ` Christian König
2021-06-17 16:48 ` Daniel Vetter
2021-06-17 18:28 ` Marek Olšák
2021-06-17 19:04 ` Daniel Vetter
2021-06-17 19:23 ` Marek Olšák
2021-06-03 3:16 ` Marek Olšák
2021-06-03 7:47 ` Daniel Vetter
2021-06-03 8:20 ` Marek Olšák
2021-06-03 10:03 ` Daniel Vetter
2021-06-03 10:55 ` Marek Olšák
2021-06-03 11:22 ` Daniel Vetter
2021-06-03 17:52 ` Marek Olšák
2021-06-03 19:18 ` Daniel Vetter
2021-06-04 5:26 ` Marek Olšák
2021-06-02 9:44 ` Christian König
2021-06-02 9:58 ` Marek Olšák [this message]
2021-06-02 10:06 ` Christian König
2021-06-01 13:18 ` Michel Dänzer
2021-06-01 17:39 ` Michel Dänzer
2021-06-01 17:42 ` Daniel Stone
2021-06-02 8:09 ` Michel Dänzer
2021-06-02 19:20 ` Daniel Vetter
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=CAAxE2A5Hrw7oqYKttEYBdd7k6onqZc8ksak5T-Ry1oKJEZtSbw@mail.gmail.com \
--to=maraeo@gmail.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=mesa-dev@lists.freedesktop.org \
--cc=michel@daenzer.net \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).