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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 A2188C4338F for ; Wed, 28 Jul 2021 15:30:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8BEEE60F91 for ; Wed, 28 Jul 2021 15:30:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237385AbhG1PaO (ORCPT ); Wed, 28 Jul 2021 11:30:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237314AbhG1PaH (ORCPT ); Wed, 28 Jul 2021 11:30:07 -0400 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A08EDC061757; Wed, 28 Jul 2021 08:30:05 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id h14so3045573wrx.10; Wed, 28 Jul 2021 08:30: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:content-transfer-encoding; bh=PGO5orqGxOkAQAyjuFowp4gIrUTAp7PM+7R6jiUynG4=; b=BfMKIt0w2M+dV5hZ8Gi6+ugs+Y9MuZ8dsZffTOTGljdDv8TG0bHfCtbs0mS/zF3vRE 6UE+o3xXlhAduVywXjrQrBXPSaL93/QrwAP+LZWy4bRPoakL1RX9kp2q3V6sN0n+1Ccd 9NzHMwZgQVs9yYvmds7zEP4XBeMhAzpQ7u3PBOTKh6WNnBPbzQPy2MMFZnpl1dnHXJpU eGgZd3z39zVgOHcd9KXKeDzHrVuDWSM4zDJdzPsdYDDs1OpaaYuZwNF9X6LnoadNKH7H iFxgCg5K6frLy7kiDtadxWTe5DC8d91PzhkviKkfPiIxhVlE16JnU0qPW2mDFa3RQw42 IVmg== 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:content-transfer-encoding; bh=PGO5orqGxOkAQAyjuFowp4gIrUTAp7PM+7R6jiUynG4=; b=ElK52GrYpWCB5T7ze5qELLpYEftABnMV1QrWD6GD/alSkB7cWpmwH7IAtnlb5YlyEN D5E+ruiGjXXvpnCmUCH5tTbOgbC6TRHK5AbdzIXT0vHdOzpFtU60hr/C5uVJcJ39WeBP 7YVlg0GqWfAbTMmH+mcdAf2nDmGVCKRkMBqmFGVZytVnbBS9Ag6Mz3ZQTR6FYfiAkr0t yAr7IdA5fSAojoe6vL35MeVzMyAWftsHpmNJ+fGN+TmHyQtBJ8YalAnF2Kbn0UmhrkMK bRYy+MLWxqSLfQaBrea6uv2YMwUFfxr9WRtvmFF2SFsr7CFoOEQ36ZaCrNvvf8GRboyz 13fQ== X-Gm-Message-State: AOAM532JTrVz/DQD+cFjBU6LgHhZyldd+S6Fjx86SrMPeCDMYTOhjngL ekp0OcP8NRGiC6KnKXh/XSr/HNlqGh1fljP0Z7Y= X-Google-Smtp-Source: ABdhPJy2p+1wHDhRbufcHC7EWE4KRZmJktPfNZHrScfzWT3BeZBWBOqZvMA/tCI22TcDazN9EtCkVunxO93zYHXcxqY= X-Received: by 2002:a5d:4e43:: with SMTP id r3mr30512016wrt.132.1627486204224; Wed, 28 Jul 2021 08:30:04 -0700 (PDT) MIME-Version: 1.0 References: <20210726233854.2453899-1-robdclark@gmail.com> <28ca4167-4a65-0ccc-36be-5fb017f6f49d@daenzer.net> <99984703-c3ca-6aae-5888-5997d7046112@daenzer.net> <04d44873-d8e6-6ae7-f0f9-17bcb484d697@amd.com> <9d5f4415-d470-3bc1-7d52-61ba739706ae@daenzer.net> In-Reply-To: <9d5f4415-d470-3bc1-7d52-61ba739706ae@daenzer.net> From: Rob Clark Date: Wed, 28 Jul 2021 08:34:13 -0700 Message-ID: Subject: Re: [RFC 0/4] dma-fence: Deadline awareness To: =?UTF-8?Q?Michel_D=C3=A4nzer?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Christian_K=C3=B6nig?= , Rob Clark , Matthew Brost , Jack Zhang , Gustavo Padovan , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Luben Tuikov , Roy Sun , Alex Deucher , Tian Tao , Lee Jones , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 28, 2021 at 6:24 AM Michel D=C3=A4nzer wro= te: > > On 2021-07-28 3:13 p.m., Christian K=C3=B6nig wrote: > > Am 28.07.21 um 15:08 schrieb Michel D=C3=A4nzer: > >> On 2021-07-28 1:36 p.m., Christian K=C3=B6nig wrote: > >>> Am 27.07.21 um 17:37 schrieb Rob Clark: > >>>> On Tue, Jul 27, 2021 at 8:19 AM Michel D=C3=A4nzer wrote: > >>>>> On 2021-07-27 5:12 p.m., Rob Clark wrote: > >>>>>> On Tue, Jul 27, 2021 at 7:50 AM Michel D=C3=A4nzer wrote: > >>>>>>> On 2021-07-27 1:38 a.m., Rob Clark wrote: > >>>>>>>> From: Rob Clark > >>>>>>>> > >>>>>>>> Based on discussion from a previous series[1] to add a "boost" m= echanism > >>>>>>>> when, for example, vblank deadlines are missed. Instead of a bo= ost > >>>>>>>> callback, this approach adds a way to set a deadline on the fenc= e, by > >>>>>>>> which the waiter would like to see the fence signalled. > >>>>>>>> > >>>>>>>> I've not yet had a chance to re-work the drm/msm part of this, b= ut > >>>>>>>> wanted to send this out as an RFC in case I don't have a chance = to > >>>>>>>> finish the drm/msm part this week. > >>>>>>>> > >>>>>>>> Original description: > >>>>>>>> > >>>>>>>> In some cases, like double-buffered rendering, missing vblanks c= an > >>>>>>>> trick the GPU into running at a lower frequence, when really we > >>>>>>>> want to be running at a higher frequency to not miss the vblanks > >>>>>>>> in the first place. > >>>>>>>> > >>>>>>>> This is partially inspired by a trick i915 does, but implemented > >>>>>>>> via dma-fence for a couple of reasons: > >>>>>>>> > >>>>>>>> 1) To continue to be able to use the atomic helpers > >>>>>>>> 2) To support cases where display and gpu are different drivers > >>>>>>>> > >>>>>>>> [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F90331%2F&data=3D04%7C01%7C= christian.koenig%40amd.com%7C269b2df3e1dc4f0b856d08d951c8c768%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637630745091538563%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp;sdata=3DeYaSOSS5wOngNAd9wufp5eWCx5GtAwo6GkultJgrjmA%3D&reserved=3D0 > >>>>>>> Unfortunately, none of these approaches will have the full intend= ed effect once Wayland compositors start waiting for client buffers to beco= me idle before using them for an output frame (to prevent output frames fro= m getting delayed by client work). See https://nam11.safelinks.protection.o= utlook.com/?url=3Dhttps%3A%2F%2Fgitlab.gnome.org%2FGNOME%2Fmutter%2F-%2Fmer= ge_requests%2F1880&data=3D04%7C01%7Cchristian.koenig%40amd.com%7C269b2d= f3e1dc4f0b856d08d951c8c768%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637= 630745091538563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI= iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D1ZkOzLqbiKSyCixGZ0u7Hd%2= Fc1YnUZub%2F%2Fx7RuEclFKg%3D&reserved=3D0 (shameless plug :) for a proo= f of concept of this for mutter. The boost will only affect the compositor'= s own GPU work, not the client work (which means no effect at all for fulls= creen apps where the compositor can scan out the client buffers directly). > >>>>>>> > >>>>>> I guess you mean "no effect at all *except* for fullscreen..."? > >>>>> I meant what I wrote: The compositor will wait for the next buffer = to become idle, so there's no boost from this mechanism for the client draw= ing to that buffer. And since the compositor does no drawing of its own in = this case, there's no boost from that either. > >>>>> > >>>>> > >>>>>> I'd perhaps recommend that wayland compositors, in cases where onl= y a > >>>>>> single layer is changing, not try to be clever and just push the > >>>>>> update down to the kernel. > >>>>> Even just for the fullscreen direct scanout case, that would requir= e some kind of atomic KMS API extension to allow queuing multiple page flip= s for the same CRTC. > >>>>> > >>>>> For other cases, this would also require a mechanism to cancel a pe= nding atomic commit, for when another surface update comes in before the co= mpositor's deadline, which affects the previously single updating surface a= s well. > >>>>> > >>>> Well, in the end, there is more than one compositor out there.. and = if > >>>> some wayland compositors are going this route, they can also impleme= nt > >>>> the same mechanism in userspace using the sysfs that devfreq exports= . > >>>> > >>>> But it sounds simpler to me for the compositor to have a sort of "ga= me > >>>> mode" for fullscreen games.. I'm less worried about UI interactive > >>>> workloads, boosting the GPU freq upon sudden activity after a period > >>>> of inactivity seems to work reasonably well there. > >>> At least AMD hardware is already capable of flipping frames on GPU ev= ents like finishing rendering (or uploading etc). > >>> > >>> By waiting in userspace on the CPU before send the frame to the hardw= are you are completely killing of such features. > >>> > >>> For composing use cases that makes sense, but certainly not for full = screen applications as far as I can see. > >> Even for fullscreen, the current KMS API only allows queuing a single = page flip per CRTC, with no way to cancel or otherwise modify it. Therefore= , a Wayland compositor has to set a deadline for the next refresh cycle, an= d when the deadline passes, it has to select the best buffer available for = the fullscreen surface. To make sure the flip will not miss the next refres= h cycle, the compositor has to pick an idle buffer. If it picks a non-idle = buffer, and the pending rendering does not finish in time for vertical blan= k, the flip will be delayed by at least one refresh cycle, which results in= visible stuttering. > >> > >> (Until the deadline passes, the Wayland compositor can't even know if = a previously fullscreen surface will still be fullscreen for the next refre= sh cycle) > > > > Well then let's extend the KMS API instead of hacking together workarou= nds in userspace. > > That's indeed a possible solution for the fullscreen / direct scanout cas= e. > > Not for the general compositing case though, since a compositor does not = want to composite multiple output frames per display refresh cycle, so it h= as to make sure the one frame hits the target. > I think solving the fullscreen game case is sufficient enough forward progress to be useful. And the results I'm seeing[1] are sufficiently positive to convince me that dma-fence deadline support is the right thing to do. But maybe the solution to make this also useful for mutter is to, once we have deadline support, extend it with an ioctl to the dma-fence fd so userspace can be the one setting the deadline. [1] https://patchwork.freedesktop.org/patch/447138/ BR, -R 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=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 C5930C4338F for ; Wed, 28 Jul 2021 15:30:07 +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 8C3D960F9D for ; Wed, 28 Jul 2021 15:30:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8C3D960F9D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id EFBAC6E1EE; Wed, 28 Jul 2021 15:30:06 +0000 (UTC) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by gabe.freedesktop.org (Postfix) with ESMTPS id C0D396E1EE for ; Wed, 28 Jul 2021 15:30:05 +0000 (UTC) Received: by mail-wr1-x429.google.com with SMTP id r2so3094712wrl.1 for ; Wed, 28 Jul 2021 08:30: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:content-transfer-encoding; bh=PGO5orqGxOkAQAyjuFowp4gIrUTAp7PM+7R6jiUynG4=; b=BfMKIt0w2M+dV5hZ8Gi6+ugs+Y9MuZ8dsZffTOTGljdDv8TG0bHfCtbs0mS/zF3vRE 6UE+o3xXlhAduVywXjrQrBXPSaL93/QrwAP+LZWy4bRPoakL1RX9kp2q3V6sN0n+1Ccd 9NzHMwZgQVs9yYvmds7zEP4XBeMhAzpQ7u3PBOTKh6WNnBPbzQPy2MMFZnpl1dnHXJpU eGgZd3z39zVgOHcd9KXKeDzHrVuDWSM4zDJdzPsdYDDs1OpaaYuZwNF9X6LnoadNKH7H iFxgCg5K6frLy7kiDtadxWTe5DC8d91PzhkviKkfPiIxhVlE16JnU0qPW2mDFa3RQw42 IVmg== 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:content-transfer-encoding; bh=PGO5orqGxOkAQAyjuFowp4gIrUTAp7PM+7R6jiUynG4=; b=pSJG4dMTvPsEg/maJzctV+/2Pe32b7xUN1esWZ+B6e7tDXRjTQ2IOOe3QtVGnUY4+0 O5CsTSIlyxxT83wB7k2nV8g3N0onEp4d8iW4fEBtHmzcpEz/RRu6uebpnZNG268siAN0 tZPMmHefr+7iUxKRPAHPcuPfRtvd9o2f2m2IRY9qDIyQjf4QmhftpMmhKl+/8cMgPRGW UHB5B9j+l/JOsWMtPILinuXJLQ9zKxUmJJKwQnql6mRvegLU7DYurOxpK+va11XtRnp2 acAMieXKkrpMZvkpAeRf+4qh/d83xP3klJpxxWNaFtRxRaeE+Kqd/64a3uv20gi6ZIMu br1A== X-Gm-Message-State: AOAM531JzVjPyuMe+BeYoP+Iuomv1rz4lcZMdoB9ftPxgCYSJ9bpEsbS qIMAXCVylDZP/AGSuU4fV3+wwPO+TZ7SnA8DHBA= X-Google-Smtp-Source: ABdhPJy2p+1wHDhRbufcHC7EWE4KRZmJktPfNZHrScfzWT3BeZBWBOqZvMA/tCI22TcDazN9EtCkVunxO93zYHXcxqY= X-Received: by 2002:a5d:4e43:: with SMTP id r3mr30512016wrt.132.1627486204224; Wed, 28 Jul 2021 08:30:04 -0700 (PDT) MIME-Version: 1.0 References: <20210726233854.2453899-1-robdclark@gmail.com> <28ca4167-4a65-0ccc-36be-5fb017f6f49d@daenzer.net> <99984703-c3ca-6aae-5888-5997d7046112@daenzer.net> <04d44873-d8e6-6ae7-f0f9-17bcb484d697@amd.com> <9d5f4415-d470-3bc1-7d52-61ba739706ae@daenzer.net> In-Reply-To: <9d5f4415-d470-3bc1-7d52-61ba739706ae@daenzer.net> From: Rob Clark Date: Wed, 28 Jul 2021 08:34:13 -0700 Message-ID: Subject: Re: [RFC 0/4] dma-fence: Deadline awareness To: =?UTF-8?Q?Michel_D=C3=A4nzer?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Rob Clark , Matthew Brost , Jack Zhang , =?UTF-8?Q?Christian_K=C3=B6nig?= , open list , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Luben Tuikov , Roy Sun , Gustavo Padovan , Alex Deucher , Tian Tao , Lee Jones , =?UTF-8?Q?Christian_K=C3=B6nig?= , "open list:DMA BUFFER SHARING FRAMEWORK" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jul 28, 2021 at 6:24 AM Michel D=C3=A4nzer wro= te: > > On 2021-07-28 3:13 p.m., Christian K=C3=B6nig wrote: > > Am 28.07.21 um 15:08 schrieb Michel D=C3=A4nzer: > >> On 2021-07-28 1:36 p.m., Christian K=C3=B6nig wrote: > >>> Am 27.07.21 um 17:37 schrieb Rob Clark: > >>>> On Tue, Jul 27, 2021 at 8:19 AM Michel D=C3=A4nzer wrote: > >>>>> On 2021-07-27 5:12 p.m., Rob Clark wrote: > >>>>>> On Tue, Jul 27, 2021 at 7:50 AM Michel D=C3=A4nzer wrote: > >>>>>>> On 2021-07-27 1:38 a.m., Rob Clark wrote: > >>>>>>>> From: Rob Clark > >>>>>>>> > >>>>>>>> Based on discussion from a previous series[1] to add a "boost" m= echanism > >>>>>>>> when, for example, vblank deadlines are missed. Instead of a bo= ost > >>>>>>>> callback, this approach adds a way to set a deadline on the fenc= e, by > >>>>>>>> which the waiter would like to see the fence signalled. > >>>>>>>> > >>>>>>>> I've not yet had a chance to re-work the drm/msm part of this, b= ut > >>>>>>>> wanted to send this out as an RFC in case I don't have a chance = to > >>>>>>>> finish the drm/msm part this week. > >>>>>>>> > >>>>>>>> Original description: > >>>>>>>> > >>>>>>>> In some cases, like double-buffered rendering, missing vblanks c= an > >>>>>>>> trick the GPU into running at a lower frequence, when really we > >>>>>>>> want to be running at a higher frequency to not miss the vblanks > >>>>>>>> in the first place. > >>>>>>>> > >>>>>>>> This is partially inspired by a trick i915 does, but implemented > >>>>>>>> via dma-fence for a couple of reasons: > >>>>>>>> > >>>>>>>> 1) To continue to be able to use the atomic helpers > >>>>>>>> 2) To support cases where display and gpu are different drivers > >>>>>>>> > >>>>>>>> [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%= 3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F90331%2F&data=3D04%7C01%7C= christian.koenig%40amd.com%7C269b2df3e1dc4f0b856d08d951c8c768%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637630745091538563%7CUnknown%7CTWFpbGZsb3d8= eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp;sdata=3DeYaSOSS5wOngNAd9wufp5eWCx5GtAwo6GkultJgrjmA%3D&reserved=3D0 > >>>>>>> Unfortunately, none of these approaches will have the full intend= ed effect once Wayland compositors start waiting for client buffers to beco= me idle before using them for an output frame (to prevent output frames fro= m getting delayed by client work). See https://nam11.safelinks.protection.o= utlook.com/?url=3Dhttps%3A%2F%2Fgitlab.gnome.org%2FGNOME%2Fmutter%2F-%2Fmer= ge_requests%2F1880&data=3D04%7C01%7Cchristian.koenig%40amd.com%7C269b2d= f3e1dc4f0b856d08d951c8c768%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637= 630745091538563%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI= iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D1ZkOzLqbiKSyCixGZ0u7Hd%2= Fc1YnUZub%2F%2Fx7RuEclFKg%3D&reserved=3D0 (shameless plug :) for a proo= f of concept of this for mutter. The boost will only affect the compositor'= s own GPU work, not the client work (which means no effect at all for fulls= creen apps where the compositor can scan out the client buffers directly). > >>>>>>> > >>>>>> I guess you mean "no effect at all *except* for fullscreen..."? > >>>>> I meant what I wrote: The compositor will wait for the next buffer = to become idle, so there's no boost from this mechanism for the client draw= ing to that buffer. And since the compositor does no drawing of its own in = this case, there's no boost from that either. > >>>>> > >>>>> > >>>>>> I'd perhaps recommend that wayland compositors, in cases where onl= y a > >>>>>> single layer is changing, not try to be clever and just push the > >>>>>> update down to the kernel. > >>>>> Even just for the fullscreen direct scanout case, that would requir= e some kind of atomic KMS API extension to allow queuing multiple page flip= s for the same CRTC. > >>>>> > >>>>> For other cases, this would also require a mechanism to cancel a pe= nding atomic commit, for when another surface update comes in before the co= mpositor's deadline, which affects the previously single updating surface a= s well. > >>>>> > >>>> Well, in the end, there is more than one compositor out there.. and = if > >>>> some wayland compositors are going this route, they can also impleme= nt > >>>> the same mechanism in userspace using the sysfs that devfreq exports= . > >>>> > >>>> But it sounds simpler to me for the compositor to have a sort of "ga= me > >>>> mode" for fullscreen games.. I'm less worried about UI interactive > >>>> workloads, boosting the GPU freq upon sudden activity after a period > >>>> of inactivity seems to work reasonably well there. > >>> At least AMD hardware is already capable of flipping frames on GPU ev= ents like finishing rendering (or uploading etc). > >>> > >>> By waiting in userspace on the CPU before send the frame to the hardw= are you are completely killing of such features. > >>> > >>> For composing use cases that makes sense, but certainly not for full = screen applications as far as I can see. > >> Even for fullscreen, the current KMS API only allows queuing a single = page flip per CRTC, with no way to cancel or otherwise modify it. Therefore= , a Wayland compositor has to set a deadline for the next refresh cycle, an= d when the deadline passes, it has to select the best buffer available for = the fullscreen surface. To make sure the flip will not miss the next refres= h cycle, the compositor has to pick an idle buffer. If it picks a non-idle = buffer, and the pending rendering does not finish in time for vertical blan= k, the flip will be delayed by at least one refresh cycle, which results in= visible stuttering. > >> > >> (Until the deadline passes, the Wayland compositor can't even know if = a previously fullscreen surface will still be fullscreen for the next refre= sh cycle) > > > > Well then let's extend the KMS API instead of hacking together workarou= nds in userspace. > > That's indeed a possible solution for the fullscreen / direct scanout cas= e. > > Not for the general compositing case though, since a compositor does not = want to composite multiple output frames per display refresh cycle, so it h= as to make sure the one frame hits the target. > I think solving the fullscreen game case is sufficient enough forward progress to be useful. And the results I'm seeing[1] are sufficiently positive to convince me that dma-fence deadline support is the right thing to do. But maybe the solution to make this also useful for mutter is to, once we have deadline support, extend it with an ioctl to the dma-fence fd so userspace can be the one setting the deadline. [1] https://patchwork.freedesktop.org/patch/447138/ BR, -R