From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: "Marek Olšák" <maraeo@gmail.com>,
"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 11:44:42 +0200 [thread overview]
Message-ID: <bbb990cf-008a-e4d3-93d3-a9adc2f202b7@gmail.com> (raw)
In-Reply-To: <CAPj87rPbiFf3qDo35gmirAoTOOJ5fEE6UxQdJKtfjX_VTqc6pg@mail.gmail.com>
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.
Regards,
Christian.
>
> Cheers,
> Daniel
next prev parent reply other threads:[~2021-06-02 9:44 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 [this message]
2021-06-02 9:58 ` Marek Olšák
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=bbb990cf-008a-e4d3-93d3-a9adc2f202b7@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jason@jlekstrand.net \
--cc=maraeo@gmail.com \
--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).