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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 91033C4338F for ; Tue, 27 Jul 2021 15:35:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6815861AE1 for ; Tue, 27 Jul 2021 15:35:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236833AbhG0PfY (ORCPT ); Tue, 27 Jul 2021 11:35:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237130AbhG0PdI (ORCPT ); Tue, 27 Jul 2021 11:33:08 -0400 Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CEF1C0613C1 for ; Tue, 27 Jul 2021 08:33:04 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id l11so12440418iln.4 for ; Tue, 27 Jul 2021 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2XSUgUmh1XmhyeIYFwsZM0972t6Q/ERgdKcfAvWCsXo=; b=WoBVP+ShhYBW3XIRtEoFeKDAxYRg7LAooItgUc/qCO5rbpT8S1SGveANY6QZow8HVV 1+hIz1ESdPIESI7nrWboMNbTJ5mQMsx82jvKEW9JV8YQll6kJkdxKFKzVgHskt4HiTj0 Ge3yAY65ZpFqupTShyti2NRxkrPatOLXsbYy4= 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=2XSUgUmh1XmhyeIYFwsZM0972t6Q/ERgdKcfAvWCsXo=; b=IjS8emtQgmN0YIGybZ0tIUlrvz6e9mQL0Y3yuZBVUvbkjGS2fEl9sjCPYAL+7uObYU eQ1x6t2CmGEp6KBySexW4kyBsa/imS1JSbppMbTe/rBJrgi47Kyjokx3aPMthtwjnHU+ K7vlPSO1d/FpGBnrwcckEfAZe+eesllv17fn0ywZ2ZWtt6Lcxst+CifDYSsRT4UnZkGc uihQXdO5RBQEFRVOceHJuUV97zxfEvk8rhHiRlcARCFR6yb5g5gjMnkiTWhhqSn92Dg8 w9hGDbKpwCLdBVy3Z6UH9S87AR+D3sF93manPXItFDmAnmfmI0gbLQTg4RLBUwIG5zyz YCqg== X-Gm-Message-State: AOAM532PxFT2kuioq2n/r5BeqFxMCOGgw/lk5y84STyXzvCV6/rHCxDs bdBSsU8JC6t5tzjHxwVnLrhBxK+zFv1lb3YK1dFVVg== X-Google-Smtp-Source: ABdhPJyp0rjZXaaLN68ns6YbN2+CaZ3yGgUttI6artx6AYKOdKEPRd2tdFT3EnbvCIWSuwrhGLn45TPUXvRSHT8R1Gk= X-Received: by 2002:a92:6f0a:: with SMTP id k10mr16658190ilc.105.1627399983576; Tue, 27 Jul 2021 08:33:03 -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> In-Reply-To: <99984703-c3ca-6aae-5888-5997d7046112@daenzer.net> From: Rob Clark Date: Tue, 27 Jul 2021 08:37:13 -0700 Message-ID: Subject: Re: [RFC 0/4] dma-fence: Deadline awareness To: =?UTF-8?Q?Michel_D=C3=A4nzer?= 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" 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 Tue, Jul 27, 2021 at 8:19 AM Michel D=C3=A4nzer wro= te: > > 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" mechan= ism > >>> when, for example, vblank deadlines are missed. Instead of a boost > >>> callback, this approach adds a way to set a deadline on the fence, 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, but > >>> 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 can > >>> 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://patchwork.freedesktop.org/series/90331/ > >> > >> Unfortunately, none of these approaches will have the full intended ef= fect once Wayland compositors start waiting for client buffers to become id= le before using them for an output frame (to prevent output frames from get= ting delayed by client work). See https://gitlab.gnome.org/GNOME/mutter/-/m= erge_requests/1880 (shameless plug :) for a proof of concept of this for mu= tter. The boost will only affect the compositor's own GPU work, not the cli= ent work (which means no effect at all for fullscreen apps where the compos= itor 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 bec= ome idle, so there's no boost from this mechanism for the client drawing to= that buffer. And since the compositor does no drawing of its own in this c= ase, there's no boost from that either. > > > > I'd perhaps recommend that wayland compositors, in cases where only 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 require some= kind of atomic KMS API extension to allow queuing multiple page flips for = the same CRTC. > > For other cases, this would also require a mechanism to cancel a pending = atomic commit, for when another surface update comes in before the composit= or's deadline, which affects the previously single updating surface as 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 implement 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 "game 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. BR, -R > > -- > Earthling Michel D=C3=A4nzer | https://redhat= .com > Libre software enthusiast | Mesa and X developer 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 CECC6C4338F for ; Tue, 27 Jul 2021 15:33:06 +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 97B9661AE1 for ; Tue, 27 Jul 2021 15:33:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 97B9661AE1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 F0BF06E938; Tue, 27 Jul 2021 15:33:05 +0000 (UTC) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4207A6E938 for ; Tue, 27 Jul 2021 15:33:04 +0000 (UTC) Received: by mail-il1-x12c.google.com with SMTP id q18so12400390ile.9 for ; Tue, 27 Jul 2021 08:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2XSUgUmh1XmhyeIYFwsZM0972t6Q/ERgdKcfAvWCsXo=; b=WoBVP+ShhYBW3XIRtEoFeKDAxYRg7LAooItgUc/qCO5rbpT8S1SGveANY6QZow8HVV 1+hIz1ESdPIESI7nrWboMNbTJ5mQMsx82jvKEW9JV8YQll6kJkdxKFKzVgHskt4HiTj0 Ge3yAY65ZpFqupTShyti2NRxkrPatOLXsbYy4= 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=2XSUgUmh1XmhyeIYFwsZM0972t6Q/ERgdKcfAvWCsXo=; b=aIUo2YwQCUqcYQs6lEveOJZYV2jPUlM51qSVNSO3/p7PHpMJwDbI4wCn2ogZQfivEj TT3UGSHWSN6CNEk+ESol/xh8BnivCzbSnr7uSkXMgO1xglpIiNgW1tr+F1GfIhuPV7z7 0ZEJaTWrTHg+fYsNGqMafbnbH/aYVNnldLOurx5Q5RTRJ/BqdTkAqBp7AI5vmim0Yn8W SuqRZIojhnRqeCLA+TEaRB31u7DzObPB07hU+iChQ6BEdll/eL5s54ttwGsBNhIzjELZ L5u+Jk2n+qqy8zHPBPxb3oze3XQ0VNCIHSL/hjIDQkxWZ/LRhJmy1t/tnbKQWvFFDhJz PSrQ== X-Gm-Message-State: AOAM531D8AdAUQnfPA61iT/gpbERsxvuhut2qrAggqtOYy1WdBdCIdPi v1v28XV5Msuesdhre4kNVwabkw4zE6zvPEYSrqzhrA== X-Google-Smtp-Source: ABdhPJyp0rjZXaaLN68ns6YbN2+CaZ3yGgUttI6artx6AYKOdKEPRd2tdFT3EnbvCIWSuwrhGLn45TPUXvRSHT8R1Gk= X-Received: by 2002:a92:6f0a:: with SMTP id k10mr16658190ilc.105.1627399983576; Tue, 27 Jul 2021 08:33:03 -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> In-Reply-To: <99984703-c3ca-6aae-5888-5997d7046112@daenzer.net> From: Rob Clark Date: Tue, 27 Jul 2021 08:37: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: 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 Tue, Jul 27, 2021 at 8:19 AM Michel D=C3=A4nzer wro= te: > > 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" mechan= ism > >>> when, for example, vblank deadlines are missed. Instead of a boost > >>> callback, this approach adds a way to set a deadline on the fence, 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, but > >>> 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 can > >>> 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://patchwork.freedesktop.org/series/90331/ > >> > >> Unfortunately, none of these approaches will have the full intended ef= fect once Wayland compositors start waiting for client buffers to become id= le before using them for an output frame (to prevent output frames from get= ting delayed by client work). See https://gitlab.gnome.org/GNOME/mutter/-/m= erge_requests/1880 (shameless plug :) for a proof of concept of this for mu= tter. The boost will only affect the compositor's own GPU work, not the cli= ent work (which means no effect at all for fullscreen apps where the compos= itor 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 bec= ome idle, so there's no boost from this mechanism for the client drawing to= that buffer. And since the compositor does no drawing of its own in this c= ase, there's no boost from that either. > > > > I'd perhaps recommend that wayland compositors, in cases where only 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 require some= kind of atomic KMS API extension to allow queuing multiple page flips for = the same CRTC. > > For other cases, this would also require a mechanism to cancel a pending = atomic commit, for when another surface update comes in before the composit= or's deadline, which affects the previously single updating surface as 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 implement 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 "game 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. BR, -R > > -- > Earthling Michel D=C3=A4nzer | https://redhat= .com > Libre software enthusiast | Mesa and X developer