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.3 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 356DCC4338F for ; Tue, 3 Aug 2021 07:34:04 +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 3D9E060C3E for ; Tue, 3 Aug 2021 07:34:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3D9E060C3E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daenzer.net 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 937906E159; Tue, 3 Aug 2021 07:34:02 +0000 (UTC) Received: from netline-mail3.netline.ch (mail.netline.ch [148.251.143.180]) by gabe.freedesktop.org (Postfix) with ESMTP id 4C2CD6E159 for ; Tue, 3 Aug 2021 07:34:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 736CF20201B; Tue, 3 Aug 2021 09:34:00 +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 E8y2sbOCKraz; Tue, 3 Aug 2021 09:34:00 +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 DD80920201A; Tue, 3 Aug 2021 09:33:59 +0200 (CEST) Received: from [::1] by thor with esmtp (Exim 4.94.2) (envelope-from ) id 1mAow2-000aZX-RS; Tue, 03 Aug 2021 09:33:58 +0200 To: "Kasireddy, Vivek" , Daniel Vetter Cc: "dri-devel@lists.freedesktop.org" , Gerd Hoffmann , Pekka Paalanen , Simon Ser , "Zhang, Tina" , "Kim, Dongwon" , "Singh, Satyeshwar" References: <20210729081659.2255499-1-vivek.kasireddy@intel.com> <612fd31a51384cb28ac6da9db3e840ca@intel.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability Message-ID: <1b96e91f-d65c-a155-8c8c-8a4326733c4e@daenzer.net> Date: Tue, 3 Aug 2021 09:33:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.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-08-03 8:11 a.m., Kasireddy, Vivek wrote: > >>> The goal: >>> - Maintain full framerate even when the Guest scanout FB is flipped onto a hardware >> plane >>> on the Host -- regardless of either compositor's scheduling policy -- without making any >>> copies and ensuring that both Host and Guest are not accessing the buffer at the same >> time. >>> >>> The problem: >>> - If the Host compositor flips the client's buffer (in this case Guest compositor's buffer) >>> onto a hardware plane, then it can send a wl_buffer.release event for the previous buffer >>> only after it gets a pageflip completion. And, if the Guest compositor takes 10-12 ms to >>> submit a new buffer and given the fact that the Host compositor waits only for 9 ms, the >>> Guest compositor will miss the Host's repaint cycle resulting in halved frame-rate. >>> >>> The solution: >>> - To ensure full framerate, the Guest compositor has to start it's repaint cycle (including >>> the 9 ms wait) when the Host compositor sends the frame callback event to its clients. >>> In order for this to happen, the dma-fence that the Guest KMS waits on -- before sending >>> pageflip completion -- cannot be tied to a wl_buffer.release event. This means that, the >>> Guest compositor has to be forced to use a new buffer for its next repaint cycle when it >>> gets a pageflip completion. >> >> Is that really the only solution? > [Kasireddy, Vivek] There are a few others I mentioned here: > https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_986572 > But I think none of them are as compelling as this one. > >> >> If we fix the event timestamps so that both guest and host use the same >> timestamp, but then the guest starts 5ms (or something like that) earlier, >> then things should work too? I.e. >> - host compositor starts at (previous_frametime + 9ms) >> - guest compositor starts at (previous_frametime + 4ms) >> >> Ofc this only works if the frametimes we hand out to both match _exactly_ >> and are as high-precision as the ones on the host side. Which for many gpu >> drivers at least is the case, and all the ones you care about for sure :-) >> >> But if the frametimes the guest receives are the no_vblank fake ones, then >> they'll be all over the place and this carefully tuned low-latency redraw >> loop falls apart. Aside fromm the fact that without tuning the guests to >> be earlier than the hosts, you're guaranteed to miss every frame (except >> when the timing wobbliness in the guest is big enough by chance to make >> the deadline on the oddball frame). > [Kasireddy, Vivek] The Guest and Host use different event timestamps as we don't > share these between the Guest and the Host. It does not seem to be causing any other > problems so far but we did try the experiment you mentioned (i.e., adjusting the delays) > and it works. However, this patch series is meant to fix the issue without having to tweak > anything (delays) because we can't do this for every compositor out there. Maybe there could be a mechanism which allows the compositor in the guest to automatically adjust its repaint cycle as needed. This might even be possible without requiring changes in each compositor, by adjusting the vertical blank periods in the guest to be aligned with the host compositor repaint cycles. Not sure about that though. Even if not, both this series or making it possible to queue multiple flips require corresponding changes in each compositor as well to have any effect. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer