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=-4.4 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,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 CF4F5C432BE for ; Thu, 29 Jul 2021 10:14:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B566D60F23 for ; Thu, 29 Jul 2021 10:14:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235737AbhG2KO0 (ORCPT ); Thu, 29 Jul 2021 06:14:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235155AbhG2KOZ (ORCPT ); Thu, 29 Jul 2021 06:14:25 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29195C061757; Thu, 29 Jul 2021 03:14:22 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id m19so3372078wms.0; Thu, 29 Jul 2021 03:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CbFHCpPlzhscajakLbbh3EIk/BRFf4SX49QUa0d5Qg8=; b=iiRfREWMNqV+qofxci/nzSz0YAr9K6MCEnf8mrHjk5y30QSLdkiVVWBq2cSSMhixN3 ry579tv1iYeCv29lJtfmG5FwAtxbT5yYu5lAVL8ZpVNvJ53JkuPkc7CG6zDCoWMOyRFX GADeLhCmxvmdJVr1mDhX6/g8ZgA2/q4W9C+er3WP4hMov+Tsm9dSAt+WgDJ4hr1RX+rn E/qLsNO2AIRIJIm5SV1Y30DYw9Cw08mbLnPBLmj4yUu3UDnnqb6cip/FaecTccXJG/e3 l5ydK+ERFnB7VVy/Ts8KO7uAifGrAIXPr/o+CFsOc3K3/kwQNLOzOSOnJJR7wDL0EEe/ Nt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CbFHCpPlzhscajakLbbh3EIk/BRFf4SX49QUa0d5Qg8=; b=gEg1wdVqeBoCZjMlzr17P84VLb7zQnnYJbm+fZosDQQP81hDfcvPquJulveK6Ry5xh a6sbueEfCgwmx8DpVloZhhbX0l/gEVsipPQk8LvjsYfh3H8ii6D0oMu/LKhPDptBvTdu gIzdts7mFBv4+2J++Rf00QT0T1lRPGl2BfTsgiBS5nm1TPlynWNRVQ0CkHfYSsNQ5Ljc 2/oblMjchVpkg4dpRuNyzYmlhYiTDnatY/Iy94DxTYD3Bgp+HtpwMQe0+vg7p72hGqKr kLBVXdG1zPi4Euz68pkadnYIMj5knhheKjgjxEpNpCWD8qNSvGkdtIyo2EI1NQNta/CK Rlyg== X-Gm-Message-State: AOAM530bSL0u0oJ3l8CODi0OJA0So1WLvEBf2rjn+OR/Boi/A54UZTNz QMYuT/kZCqysKA1pxM5FpCWQuzYL5RH3wA== X-Google-Smtp-Source: ABdhPJz5727odHJWfYQdPwGMdYsRDkR36uAkRZDsHt9CJwGj6udF1FY1AywRQgAgB56AGxuvCy2G9A== X-Received: by 2002:a1c:a7d2:: with SMTP id q201mr13967106wme.61.1627553660808; Thu, 29 Jul 2021 03:14:20 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:4b10:6e80:f619:9837? ([2a02:908:1252:fb60:4b10:6e80:f619:9837]) by smtp.gmail.com with ESMTPSA id d14sm2751552wrs.49.2021.07.29.03.14.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 03:14:20 -0700 (PDT) Subject: Re: [RFC 0/4] dma-fence: Deadline awareness To: Pekka Paalanen , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: =?UTF-8?Q?Michel_D=c3=a4nzer?= , 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" 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> <20210728165700.38c39cf8@eldfell> <74e310fa-e544-889f-2389-5abe06f80eb8@amd.com> <20210729112358.237651ff@eldfell> <3675d530-c9fc-7ec9-e157-b6abeeec7c2a@amd.com> <20210729121542.27d9b1cc@eldfell> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <15cf73a8-eda4-3559-561a-a05a14f445d0@gmail.com> Date: Thu, 29 Jul 2021 12:14:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210729121542.27d9b1cc@eldfell> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 29.07.21 um 11:15 schrieb Pekka Paalanen: > [SNIP] >> But how does it then help to wait on the CPU instead? > A compositor does not "wait" literally. It would only check which state > set is ready to be used, and uses the most recent set that is ready. Any > state sets that are not ready are ignored and reconsidered the next > time the compositor updates the screen. Mhm, then I'm not understanding what Michel's changes are actually doing. > Depending on which state sets are selected for a screen update, the > global window manager state may be updated accordingly, before the > drawing commands for the composition can be created. > >> See what I'm proposing is to either render the next state of the window >> or compose from the old state (including all atomic properties). > Yes, that's exactly how it would work. It's just that state for a > window is not an independent thing, it can affect how unrelated windows > are managed. > > A simplified example would be two windows side by side where the > resizing of one causes the other to move. You can't resize the window > or move the other until the buffer with the new size is ready. Until > then the compositor uses the old state. > >> E.g. what do you do if you timeout and can't have the new window content >> on time? What's the fallback here? > As there is no wait, there is no timeout either. > > If the app happens to be frozen (e.g. some weird bug in fence handling > to make it never ready, or maybe it's just bugged itself and never > drawing again), then the app is frozen, and all the rest of the desktop > continues running normally without a glitch. But that is in contradict to what you told me before. See when the window should move but fails to draw it's new content what happens? Are the other windows which would be affected by the move not drawn as well? Regards, Christian. > > > Thanks, > pq 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.2 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,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 E57A7C4338F for ; Thu, 29 Jul 2021 10:14:23 +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 AB10260F23 for ; Thu, 29 Jul 2021 10:14:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AB10260F23 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 0BEFD6E0AF; Thu, 29 Jul 2021 10:14:23 +0000 (UTC) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by gabe.freedesktop.org (Postfix) with ESMTPS id 423686E0AF for ; Thu, 29 Jul 2021 10:14:22 +0000 (UTC) Received: by mail-wm1-x330.google.com with SMTP id n21so3348001wmq.5 for ; Thu, 29 Jul 2021 03:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CbFHCpPlzhscajakLbbh3EIk/BRFf4SX49QUa0d5Qg8=; b=iiRfREWMNqV+qofxci/nzSz0YAr9K6MCEnf8mrHjk5y30QSLdkiVVWBq2cSSMhixN3 ry579tv1iYeCv29lJtfmG5FwAtxbT5yYu5lAVL8ZpVNvJ53JkuPkc7CG6zDCoWMOyRFX GADeLhCmxvmdJVr1mDhX6/g8ZgA2/q4W9C+er3WP4hMov+Tsm9dSAt+WgDJ4hr1RX+rn E/qLsNO2AIRIJIm5SV1Y30DYw9Cw08mbLnPBLmj4yUu3UDnnqb6cip/FaecTccXJG/e3 l5ydK+ERFnB7VVy/Ts8KO7uAifGrAIXPr/o+CFsOc3K3/kwQNLOzOSOnJJR7wDL0EEe/ Nt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CbFHCpPlzhscajakLbbh3EIk/BRFf4SX49QUa0d5Qg8=; b=iuGxFfuhhNfl5zjCmQJ+QwhiDQqXwy4DHOF/EYFqHdE2NWBjxLvFgXsN0YF4AIg0iN LHdx1VkFzTFnkns2AVRo0s/9ySVP5udNCLLj57CV/MuxVvE1by1bB8e9TLwYS20FukiB 5sHrxKTADi8NfF895HvlCq39GS59iSSm9uMJi+2vepl2AvmYy6914o/nyLzdtuHJd7l9 ZLNXK+Ve0HbmovDVKe8ZTrRewgdmklp7pb9bhNNhnrePk+qHiBK2w664cZKdC1JugfTM TAMG9gxPzNAZwmhekiVt76M6+akKB2Ww2ijS2/h9KOszG1p+lRPpdlpY7Vxr2Gd4rfcD E7sA== X-Gm-Message-State: AOAM532Y4gOiwAqwCR6tE+MBeztA9QR7JsO+c7MdyOr39oMbHOLBPqKJ sp4NvkYGxO1CUfi8koTYxQk= X-Google-Smtp-Source: ABdhPJz5727odHJWfYQdPwGMdYsRDkR36uAkRZDsHt9CJwGj6udF1FY1AywRQgAgB56AGxuvCy2G9A== X-Received: by 2002:a1c:a7d2:: with SMTP id q201mr13967106wme.61.1627553660808; Thu, 29 Jul 2021 03:14:20 -0700 (PDT) Received: from ?IPv6:2a02:908:1252:fb60:4b10:6e80:f619:9837? ([2a02:908:1252:fb60:4b10:6e80:f619:9837]) by smtp.gmail.com with ESMTPSA id d14sm2751552wrs.49.2021.07.29.03.14.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Jul 2021 03:14:20 -0700 (PDT) Subject: Re: [RFC 0/4] dma-fence: Deadline awareness To: Pekka Paalanen , =?UTF-8?Q?Christian_K=c3=b6nig?= 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> <20210728165700.38c39cf8@eldfell> <74e310fa-e544-889f-2389-5abe06f80eb8@amd.com> <20210729112358.237651ff@eldfell> <3675d530-c9fc-7ec9-e157-b6abeeec7c2a@amd.com> <20210729121542.27d9b1cc@eldfell> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <15cf73a8-eda4-3559-561a-a05a14f445d0@gmail.com> Date: Thu, 29 Jul 2021 12:14:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210729121542.27d9b1cc@eldfell> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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 , Gustavo Padovan , =?UTF-8?Q?Michel_D=c3=a4nzer?= , 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" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Am 29.07.21 um 11:15 schrieb Pekka Paalanen: > [SNIP] >> But how does it then help to wait on the CPU instead? > A compositor does not "wait" literally. It would only check which state > set is ready to be used, and uses the most recent set that is ready. Any > state sets that are not ready are ignored and reconsidered the next > time the compositor updates the screen. Mhm, then I'm not understanding what Michel's changes are actually doing. > Depending on which state sets are selected for a screen update, the > global window manager state may be updated accordingly, before the > drawing commands for the composition can be created. > >> See what I'm proposing is to either render the next state of the window >> or compose from the old state (including all atomic properties). > Yes, that's exactly how it would work. It's just that state for a > window is not an independent thing, it can affect how unrelated windows > are managed. > > A simplified example would be two windows side by side where the > resizing of one causes the other to move. You can't resize the window > or move the other until the buffer with the new size is ready. Until > then the compositor uses the old state. > >> E.g. what do you do if you timeout and can't have the new window content >> on time? What's the fallback here? > As there is no wait, there is no timeout either. > > If the app happens to be frozen (e.g. some weird bug in fence handling > to make it never ready, or maybe it's just bugged itself and never > drawing again), then the app is frozen, and all the rest of the desktop > continues running normally without a glitch. But that is in contradict to what you told me before. See when the window should move but fails to draw it's new content what happens? Are the other windows which would be affected by the move not drawn as well? Regards, Christian. > > > Thanks, > pq