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 17AA4C433EF for ; Thu, 9 Sep 2021 17:03:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E917561167 for ; Thu, 9 Sep 2021 17:03:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239891AbhIIRFH (ORCPT ); Thu, 9 Sep 2021 13:05:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234524AbhIIRFG (ORCPT ); Thu, 9 Sep 2021 13:05:06 -0400 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5C94C061574; Thu, 9 Sep 2021 10:03:56 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id x6so3526387wrv.13; Thu, 09 Sep 2021 10:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IbPPNqobPmWZ9MF50JtcVBJ+K5zUi+K+HgQrnexV6is=; b=BE/y2bL/mHyRfUxGmarxT/nWkFdJyoDiJQtSLvbtElf2UESCirtPhVWa0xURMyE5tF rYTmwmayvMNAV77nMn8OnSbsQBXKaho0Mf7sx1UJRiNp/0zyvd2vEvD1ZcsOP6Idyh8I nJMdkiJveWXI8MXP3/S+LHsYohhkLiI5HAvtYoDeM1SJxY7AIldHjSqxxEhtIkYmYB84 5QNzYwGK3ubwMbqUocdIOoNCwQeHafOucLmkD0NJibGsl58DOIzZPkxc1wHSjsdtDsMX 7FbfsGNMPGgQl1HAh6ggsseaIz9cj2Sa7YnMJe1vCa6t0dT04seBaMEuTQ7jh5W87Jol XAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IbPPNqobPmWZ9MF50JtcVBJ+K5zUi+K+HgQrnexV6is=; b=rxQGOUzpOgv47146cQYjpF4xtGug1sWiwAr19bMy8DjEiTOj0V5jQjOGKgJI3WHzWb BoWXoUdNa7zu37A/KagANAV1yZciXq21GhVyjRBIeVq1Cb9H/Ml++770UTQo6ijkK/Ty v1xT0FyVt2f0yJuq0RoqREbcbe88eh7F5z0B803ZEOx6Dk2av2L3GWAxrxVPWJfjBer6 6i0goL30lKALNTHlFBAnQ6jruxiw5Hi5T9Kfjc5KGIAut2wtd1gLRQG6cEj8orcNYK/2 CUEX3oDm6GNDH0DHYiPGuueUQaKEVL4Iip/5qcJC9kDZQ8zWX1JFfO9nSNR8JoFd8lKN 8iTg== X-Gm-Message-State: AOAM530DG6I3HpxTS6rhlNJAf/OJ40YvpEFLIpfYFN05/Iz9Ef8Fz3WX QFCBaIIJQpJPF7MMFdsab7a6J6o5TluPUpzSr90= X-Google-Smtp-Source: ABdhPJxhkpYn5lOEWS5HH3Rm8m0d/wuvw1EtxFJjV07j/rVitgQQ8dAircwjT8ySc+dDGJd0RC694oWjtFnG4vZItxk= X-Received: by 2002:a05:6000:178b:: with SMTP id e11mr4750688wrg.151.1631207035454; Thu, 09 Sep 2021 10:03:55 -0700 (PDT) MIME-Version: 1.0 References: <20210903184806.1680887-1-robdclark@gmail.com> In-Reply-To: From: Rob Clark Date: Thu, 9 Sep 2021 10:08:22 -0700 Message-ID: Subject: Re: [PATCH v3 0/9] dma-fence: Deadline awareness To: Simon Ser Cc: dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Daniel Vetter , =?UTF-8?Q?Christian_K=C3=B6nig?= , =?UTF-8?Q?Michel_D=C3=A4nzer?= , Pekka Paalanen , Rob Clark , Alex Deucher , Andrey Grodzovsky , Boris Brezillon , =?UTF-8?Q?Christian_K=C3=B6nig?= , Daniel Vetter , freedreno , Gustavo Padovan , linux-arm-msm , Linux Kernel Mailing List , "open list:DMA BUFFER SHARING FRAMEWORK" , Luben Tuikov , Melissa Wen , Steven Price , Tian Tao Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Thu, Sep 9, 2021 at 9:42 AM Simon Ser wrote: > > On Thursday, September 9th, 2021 at 18:31, Rob Clark wrote: > > > Yes, I think it would.. and "dma-buf/sync_file: Add SET_DEADLINE > > ioctl" adds such an ioctl.. just for the benefit of igt tests at this > > point, but the thought was it would be also used by compositors that > > are doing such frame scheduling. Ofc danvet is a bit grumpy that > > there isn't a more real (than igt) userspace for the ioctl yet ;-) > > Ah, very nice, I somehow missed it. > > I guess one issue is that explicit sync isn't quite plumbed through > compositors yet, so without Jason's DMA-BUF to sync_file IOCTL it'd be > a bit difficult to use. > > Can anybody set the deadline? I wonder if clients should be allowed to. In its current form, anyone who has the fd can.. I'm not sure how (or even if) we could limit it beyond that. I suppose hypothetically you could use this for completely non-compositor related things, like compute jobs where you want the result by some deadline. (OTOH, it could be the driver using this internally when the app is stalling on a result) > What happens if the deadline is exceeded? I'd assume nothing in > particular, the deadline being just a hint? Nothing in particular, it is just a hint. The main intention is to provide a feedback hint to the drivers in scenarios like vblank deadlines, where being 1ms late is just as bad as being $frame_duration-1ms late. From my experiments and profiling it is useful in a couple scenarios: 1) input latency, ie. go from idle to fullscreen animation, where GPU has been idle for a while and not busy enough *yet* for devfreq to kick in and start ramping up the freq before we miss the first vblank 2) double buffering, for ex. if you are 1ms late you end up stalling 15ms before the gpu can start rendering the next frame.. in the absence of feedback, devfreq would ramp down in this scenario instead of up BR, -R