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=-5.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 E2153C47080 for ; Tue, 1 Jun 2021 13:18:16 +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 CE9EF610C9 for ; Tue, 1 Jun 2021 13:18:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE9EF610C9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daenzer.net 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 580126E8CA; Tue, 1 Jun 2021 13:18:15 +0000 (UTC) Received: from netline-mail3.netline.ch (mail.netline.ch [148.251.143.180]) by gabe.freedesktop.org (Postfix) with ESMTP id 609876E8CA; Tue, 1 Jun 2021 13:18:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 4F15C20201E; Tue, 1 Jun 2021 15:18:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BjsboEQiFjuM; Tue, 1 Jun 2021 15:18:12 +0200 (CEST) Received: from thor (24.99.2.85.dynamic.wline.res.cust.swisscom.ch [85.2.99.24]) by netline-mail3.netline.ch (Postfix) with ESMTPA id 703DD20201A; Tue, 1 Jun 2021 15:18:12 +0200 (CEST) Received: from localhost ([::1]) by thor with esmtp (Exim 4.94.2) (envelope-from ) id 1lo4Hb-001qUT-0H; Tue, 01 Jun 2021 15:18:11 +0200 To: =?UTF-8?Q?Christian_K=c3=b6nig?= , =?UTF-8?B?TWFyZWsgT2zFocOhaw==?= , dri-devel , ML Mesa-dev , Alex Deucher , Daniel Vetter , Dave Airlie , Jason Ekstrand , Bas Nieuwenhuizen References: <327e4008-b29f-f5b7-bb30-532fa52c797f@gmail.com> <7f19e3c7-b6b2-5200-95eb-3fed8d22a6b3@daenzer.net> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [Mesa-dev] Linux Graphics Next: Userspace submission update Message-ID: <1945baa6-95d4-3f59-0c0e-01ae65033018@daenzer.net> Date: Tue, 1 Jun 2021 15:18:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2021-06-01 2:10 p.m., Christian König wrote: > Am 01.06.21 um 12:49 schrieb Michel Dänzer: >> On 2021-06-01 12:21 p.m., Christian König wrote: >>> Am 01.06.21 um 11:02 schrieb Michel Dänzer: >>>> On 2021-05-27 11:51 p.m., Marek Olšák wrote: >>>>> 3) Compositors (and other privileged processes, and display flipping) can't trust imported/exported fences. They need a timeout recovery mechanism from the beginning, and the following are some possible solutions to timeouts: >>>>> >>>>> a) use a CPU wait with a small absolute timeout, and display the previous content on timeout >>>>> b) use a GPU wait with a small absolute timeout, and conditional rendering will choose between the latest content (if signalled) and previous content (if timed out) >>>>> >>>>> The result would be that the desktop can run close to 60 fps even if an app runs at 1 fps. >>>> FWIW, this is working with >>>> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 , even with implicit sync (on current Intel GPUs; amdgpu/radeonsi would need to provide the same dma-buf poll semantics as other drivers and high priority GFX contexts via EGL_IMG_context_priority which can preempt lower priority ones). >>> Yeah, that is really nice to have. >>> >>> One question is if you wait on the CPU or the GPU for the new surface to become available? >> It's based on polling dma-buf fds, i.e. CPU. >> >>> The former is a bit bad for latency and power management. >> There isn't a choice for Wayland compositors in general, since there can be arbitrary other state which needs to be applied atomically together with the new buffer. (Though in theory, a compositor might get fancy and special-case surface commits which can be handled by waiting on the GPU) >> >> Latency is largely a matter of scheduling in the compositor. The latency incurred by the compositor shouldn't have to be more than single-digit milliseconds. (I've seen total latency from when the client starts processing a (static) frame to when it starts being scanned out as low as ~6 ms with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1620, lower than typical with Xorg) > > Well let me describe it like this: > > We have an use cases for 144 Hz guaranteed refresh rate. That essentially means that the client application needs to be able to spit out one frame/window content every ~6.9ms. That's tough, but doable. > > When you now add 6ms latency in the compositor that means the client application has only .9ms left for it's frame which is basically impossible to do. You misunderstood me. 6 ms is the lowest possible end-to-end latency from client to scanout, but the client can start as early as it wants/needs to. It's a trade-off between latency and the risk of missing a scanout cycle. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer