From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AB9AC47083 for ; Wed, 2 Jun 2021 09:35:08 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BBD5A613BF for ; Wed, 2 Jun 2021 09:35:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBD5A613BF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7F5776EC21; Wed, 2 Jun 2021 09:35:06 +0000 (UTC) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 193DD6EC1F; Wed, 2 Jun 2021 09:35:05 +0000 (UTC) Received: by mail-pj1-x102f.google.com with SMTP id m13-20020a17090b068db02901656cc93a75so3119488pjz.3; Wed, 02 Jun 2021 02:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F9PtPpEdFhiyQ1Uzc4W7Gm8hs4lW9XiFuf5Lzw+Xcko=; b=Q6JUgvqncWZvzZMpi0I9fPvcv/BR6wwgOSc9ItOoUXUd3PA24mAFaurflCUv46/i9F e2IRHIhDnKc/2aW0nO5fRRUDfYwnZE9qnFDpfY3Ewyleo8X9lXMxkykZhvCJNzg0XR5h kCips/jjMnVyXEyZXilIx5T7HLNeb/b4Dn3apljzO2+ITXHdM6ulJFJXni7rWP0zwjas zJblB9dTeEq4O24b6/QHrfq6SheAKkPO42w3ossqVJtlKM8D0c8/xzFFVnxz/jdbI1ec VI90wGEYFUI43epMu95NQh+JA2LbUzjI8NVpyfLOqwU8TjnT600lHKgdIyEFxLB1PUSv TyFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F9PtPpEdFhiyQ1Uzc4W7Gm8hs4lW9XiFuf5Lzw+Xcko=; b=mNPgXUXFwRDziq8gP8jBmgz2ZaUmlBIskV1MtrNI1CIcaXSM57rYHnk79VHY61qa6z 5JUc6UBoo2ZgNU+zvO5iU4K4FYb90j8QFaT19Epi5xNBpfAvMjTaC/EpBNsXoDEizzDG OEAodNqPgI1wKayc06Na824S3Q2yjlYSiadJ6//0v8euqNlAWp+wSuWK3v5iFOKAT2Gi 7iQxbwnAxnVsSmv/IeCG5YmvI6mQSg/FPKpfGSq59XUu6T9ehS4w785HOtUJc6rUP2gg 6ECub1HdCyHTnbkz0eaWqIL/C3tGo2TV4z+ZbokZFBCbXZq5+Ik/Z5acZ0RuNPbTuODb vueA== X-Gm-Message-State: AOAM531ht9EjZv8VePZdl5OIBUCOG54X2PFkQQAIncFyLwpj4A2QLoeG 18ggAbA6j2fKUCzlk3YD0YaCkdOpPE8YkxsY2e8= X-Google-Smtp-Source: ABdhPJxUD7Gjfaye7P4SkguzPUFmWtxjmpjV2xWBIWi/hhIGHVoYP1YAITnh5n9DDakmDX7EesVYT31rlX5EkbBS27o= X-Received: by 2002:a17:90a:b28d:: with SMTP id c13mr4655428pjr.80.1622626504672; Wed, 02 Jun 2021 02:35:04 -0700 (PDT) MIME-Version: 1.0 References: <327e4008-b29f-f5b7-bb30-532fa52c797f@gmail.com> <7f19e3c7-b6b2-5200-95eb-3fed8d22a6b3@daenzer.net> In-Reply-To: From: =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= Date: Wed, 2 Jun 2021 05:34:28 -0400 Message-ID: Subject: Re: [Mesa-dev] Linux Graphics Next: Userspace submission update To: Daniel Stone Content-Type: multipart/alternative; boundary="0000000000006a093905c3c52cda" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Michel_D=C3=A4nzer?= , dri-devel , Jason Ekstrand , ML Mesa-dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --0000000000006a093905c3c52cda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, we can't break anything because we don't want to complicate things for us. It's pretty much all NAK'd already. We are trying to gather more knowledge and then make better decisions. The idea we are considering is that we'll expose memory-based sync objects to userspace for read only, and the kernel or hw will strictly control the memory writes to those sync objects. The hole in that idea is that userspace can decide not to signal a job, so even if userspace can't overwrite memory-based sync object states arbitrarily, it can still decide not to signal them, and then a future fence is born. Marek On Wed, Jun 2, 2021 at 4:57 AM Daniel Stone wrote: > Hi Christian, > > On Tue, 1 Jun 2021 at 13:51, Christian K=C3=B6nig > 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? > > 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. > > Cheers, > Daniel > --0000000000006a093905c3c52cda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, we can't break anything because we don't= want to complicate things for us. It's pretty much all NAK'd alrea= dy. We are trying to gather more knowledge and then make better decisions.<= /div>

The idea we are considering is that we'll expo= se memory-based sync objects to userspace for read only, and the kernel or = hw will strictly control the memory writes to those sync objects. The hole = in that idea is that userspace can decide not to signal a job, so even if u= serspace can't overwrite memory-based sync object states arbitrarily, i= t can still decide not to signal them, and then a future fence is born.

Marek

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 2, 2021 at 4:57 AM Daniel = Stone <daniel@fooishbar.org&= gt; wrote:
Hi Ch= ristian,

On Tue, 1 Jun 2021 at 13:51, Christian K=C3=B6nig
<c= koenig.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 EG= LStreams.
> > 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?

I mean, my answer to the first email is 'no, absolutely not' from t= he
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 ju= st
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.

Cheers,
Daniel
--0000000000006a093905c3c52cda--