Message ID | 20230218211608.1630586-11-robdclark@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp554200wrn; Sat, 18 Feb 2023 13:17:49 -0800 (PST) X-Google-Smtp-Source: AK7set+7H1cdSsSnRXecqykL4g0JZy3O2AmhewaJXntflsnISjshtjowwNz154jVHZswySi9/SUv X-Received: by 2002:a05:6a00:10c9:b0:5a8:a751:d22 with SMTP id d9-20020a056a0010c900b005a8a7510d22mr11051450pfu.12.1676755068767; Sat, 18 Feb 2023 13:17:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676755068; cv=none; d=google.com; s=arc-20160816; b=fdqqJGx67JFpCYKDkw6QFY2MfPSkD8DnkNPVS77REEwRd2HzwYhWB7sTDN3anPOkMs PNWwPrDvVkL12mUiZk0iLsn7lHSLkuYBz3A/q7Nk46AEk/tjrZqo3CUsgTnnSD+8yhy1 8Q3OSLgqmwOhwXuaBwar5hCmXPcROKyM4OIcJnHpBiFQ2vgJt1uSQfwjaoqWwd7H6EBe /Pz/Z1lrZKWhWV4U0FhhcGF282aMTdsZ1RXYg7bI6xRujNSsXgiyR+mObD6mP5+inRco sJAtX921glTaBm9DhMZron9IrTrFS+jas8GuF/4qRE4vgv7tDEjZGJ9qRStJ0/wrg+1a Xkkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=5Jl0bAAXIZTjQ7NsDAeqTzIEhvjQzgg5/X7BsK4u81Y=; b=dxWXF2GH2sq+BSWXXWreTFzRdjkK868kWD98gHVWk8xBdBJIijomyBJHZZsgO4dfwt n6s1o+aQe+3myaazu1gfYnYTZtLFgL8D35Z1O744MK0vnhZd5j3mG9V1xHtBE6sXhv0x x6IQVm7ZbxyELdiwfT5MyOq33hNzDsCyHb9vPiNsqw03PmiJ+OD4j6HAeTSg/X81MURK iYKYL7H4dhspLIK8fKL+9E9Nk3kaAhlTDu9FvGVO8Fe5wbfcAXKU5w3KaPVdC2RkLm9H dVkUUpqZjPNm+/V1p8r1b88BJG7sYu22DUh3BvCcmgeQkbXUgXT4nvpyK5Hv5bYB0txm IvRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Ypm3OEaE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 204-20020a6216d5000000b005a8e0855ae6si8460741pfw.179.2023.02.18.13.17.35; Sat, 18 Feb 2023 13:17:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Ypm3OEaE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbjBRVRG (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Sat, 18 Feb 2023 16:17:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42730 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229897AbjBRVQK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 18 Feb 2023 16:16:10 -0500 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE7CD13D7E for <linux-kernel@vger.kernel.org>; Sat, 18 Feb 2023 13:16:02 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id j10so703975pfn.4 for <linux-kernel@vger.kernel.org>; Sat, 18 Feb 2023 13:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5Jl0bAAXIZTjQ7NsDAeqTzIEhvjQzgg5/X7BsK4u81Y=; b=Ypm3OEaEuberWEEJkwjckxIjd/fHXeD+UsK2sNxPfOh4VXSeIeHxGyby2GuFmyckgB DPDPfvmi2uvJ7m2w9ZXK3H1Ekv2+II/tBc0aGXy3LefRYqgovm0DXtFUG/3/66OJN4iE YqOAZ7tRtVL4IMhiN+VmmAehUqGvglfHf9UTRFLCXJlwg8IMcrNqpT87lm7YhFL2srhA /yf3cvPBlakDzzA63dLpzDbxyi8W6tpPJBgG/p8y808RF05uk0cx38i6cB7r5fBCuZdJ JXI1niL29wo25W9KmsKxhyFpm2IP/w+0LZnJz4MIoDp2aP//Ap8lQlE41lyS6/oyFtPJ 1IUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Jl0bAAXIZTjQ7NsDAeqTzIEhvjQzgg5/X7BsK4u81Y=; b=UncEU8NVXfzQzhrsxsy+WaZUBEfEEO4c6fwSP/Rc1N8SoFFSdhB3PZbP0L9qymnucA Jlifjmn66EA+OjxnGJOQwGIGqs7Jgn/v9J1MRuUQI9BoUr3XjRrXCqIJG6CrbE/KxCNw QWvLOLyK4gKFN7H8rDK7ZdL21n6UCRciDhy6HLuLvAFmm6d1WlvL10xLdXwW+XM1iA/Z J1iOORyrX2RnVchbE8yny8KUBk3dPmD8qXse2u/sM6v/++S/hKf35NMHgTs4bNE09Dt6 XfbZWoam/keZFfPG8PY5zMxQJPTgzwitEQfeu9y9vs+iUu1Ir3S36YfDtAHvNpuGOz6u gmyA== X-Gm-Message-State: AO0yUKXkUqVyuoH2FE/VFBH7dO9YIyBJ/sdEA83/471Z8Hj6uYtqPmYn 9hnxXq/2R7vN0/8G8HwArW4= X-Received: by 2002:a05:6a00:4106:b0:5a8:9858:750a with SMTP id bu6-20020a056a00410600b005a89858750amr9007439pfb.13.1676754962150; Sat, 18 Feb 2023 13:16:02 -0800 (PST) Received: from localhost (c-73-67-135-195.hsd1.or.comcast.net. [73.67.135.195]) by smtp.gmail.com with ESMTPSA id s26-20020aa78d5a000000b0058dbb5c5038sm4957450pfe.182.2023.02.18.13.16.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Feb 2023 13:16:01 -0800 (PST) From: Rob Clark <robdclark@gmail.com> To: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>, =?utf-8?q?Christian_K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com>, =?utf-8?q?Michel_D=C3=A4nzer?= <michel@daenzer.net>, Tvrtko Ursulin <tvrtko.ursulin@intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Alex Deucher <alexander.deucher@amd.com>, Pekka Paalanen <ppaalanen@gmail.com>, Simon Ser <contact@emersion.fr>, Rob Clark <robdclark@chromium.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, linux-kernel@vger.kernel.org (open list) Subject: [PATCH v4 10/14] drm/vblank: Add helper to get next vblank time Date: Sat, 18 Feb 2023 13:15:53 -0800 Message-Id: <20230218211608.1630586-11-robdclark@gmail.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230218211608.1630586-1-robdclark@gmail.com> References: <20230218211608.1630586-1-robdclark@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758205122760189436?= X-GMAIL-MSGID: =?utf-8?q?1758205122760189436?= |
Series |
dma-fence: Deadline awareness
|
|
Commit Message
Rob Clark
Feb. 18, 2023, 9:15 p.m. UTC
From: Rob Clark <robdclark@chromium.org> Will be used in the next commit to set a deadline on fences that an atomic update is waiting on. Signed-off-by: Rob Clark <robdclark@chromium.org> --- drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ include/drm/drm_vblank.h | 1 + 2 files changed, 33 insertions(+)
Comments
On Sat, 18 Feb 2023 13:15:53 -0800 Rob Clark <robdclark@gmail.com> wrote: > From: Rob Clark <robdclark@chromium.org> > > Will be used in the next commit to set a deadline on fences that an > atomic update is waiting on. > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > include/drm/drm_vblank.h | 1 + > 2 files changed, 33 insertions(+) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 2ff31717a3de..caf25ebb34c5 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > } > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > +/** > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > + * @crtc: the crtc for which to calculate next vblank time > + * @vblanktime: pointer to time to receive the next vblank timestamp. > + * > + * Calculate the expected time of the next vblank based on time of previous > + * vblank and frame duration Hi, for VRR this targets the highest frame rate possible for the current VRR mode, right? Thanks, pq > + */ > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > +{ > + unsigned int pipe = drm_crtc_index(crtc); > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > + u64 count; > + > + if (!vblank->framedur_ns) > + return -EINVAL; > + > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > + > + /* > + * If we don't get a valid count, then we probably also don't > + * have a valid time: > + */ > + if (!count) > + return -EINVAL; > + > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > + > + return 0; > +} > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > + > static void send_vblank_event(struct drm_device *dev, > struct drm_pending_vblank_event *e, > u64 seq, ktime_t now) > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > index 733a3e2d1d10..a63bc2c92f3c 100644 > --- a/include/drm/drm_vblank.h > +++ b/include/drm/drm_vblank.h > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > ktime_t *vblanktime); > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > struct drm_pending_vblank_event *e); > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > On Sat, 18 Feb 2023 13:15:53 -0800 > Rob Clark <robdclark@gmail.com> wrote: > > > From: Rob Clark <robdclark@chromium.org> > > > > Will be used in the next commit to set a deadline on fences that an > > atomic update is waiting on. > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > --- > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > include/drm/drm_vblank.h | 1 + > > 2 files changed, 33 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index 2ff31717a3de..caf25ebb34c5 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > } > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > +/** > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > + * @crtc: the crtc for which to calculate next vblank time > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > + * > > + * Calculate the expected time of the next vblank based on time of previous > > + * vblank and frame duration > > Hi, > > for VRR this targets the highest frame rate possible for the current > VRR mode, right? > It is based on vblank->framedur_ns which is in turn based on mode->crtc_clock. Presumably for VRR that ends up being a maximum? BR, -R > > Thanks, > pq > > > + */ > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > +{ > > + unsigned int pipe = drm_crtc_index(crtc); > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > + u64 count; > > + > > + if (!vblank->framedur_ns) > > + return -EINVAL; > > + > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > + > > + /* > > + * If we don't get a valid count, then we probably also don't > > + * have a valid time: > > + */ > > + if (!count) > > + return -EINVAL; > > + > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > + > > static void send_vblank_event(struct drm_device *dev, > > struct drm_pending_vblank_event *e, > > u64 seq, ktime_t now) > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > --- a/include/drm/drm_vblank.h > > +++ b/include/drm/drm_vblank.h > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > ktime_t *vblanktime); > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > struct drm_pending_vblank_event *e); > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, >
On Mon, 20 Feb 2023 07:55:41 -0800 Rob Clark <robdclark@gmail.com> wrote: > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > Will be used in the next commit to set a deadline on fences that an > > > atomic update is waiting on. > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > --- > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > include/drm/drm_vblank.h | 1 + > > > 2 files changed, 33 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > --- a/drivers/gpu/drm/drm_vblank.c > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > } > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > +/** > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > + * @crtc: the crtc for which to calculate next vblank time > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > + * > > > + * Calculate the expected time of the next vblank based on time of previous > > > + * vblank and frame duration > > > > Hi, > > > > for VRR this targets the highest frame rate possible for the current > > VRR mode, right? > > > > It is based on vblank->framedur_ns which is in turn based on > mode->crtc_clock. Presumably for VRR that ends up being a maximum? I don't know. :-) You need a number of clock cycles in addition to the clock frequency, and that could still be minimum, maximum, the last realized one, ... VRR works by adjusting the front porch length IIRC. Thanks, pq > BR, > -R > > > > > > Thanks, > > pq > > > > > + */ > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > > +{ > > > + unsigned int pipe = drm_crtc_index(crtc); > > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > > + u64 count; > > > + > > > + if (!vblank->framedur_ns) > > > + return -EINVAL; > > > + > > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > > + > > > + /* > > > + * If we don't get a valid count, then we probably also don't > > > + * have a valid time: > > > + */ > > > + if (!count) > > > + return -EINVAL; > > > + > > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > > + > > > + return 0; > > > +} > > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > > + > > > static void send_vblank_event(struct drm_device *dev, > > > struct drm_pending_vblank_event *e, > > > u64 seq, ktime_t now) > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > > --- a/include/drm/drm_vblank.h > > > +++ b/include/drm/drm_vblank.h > > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > ktime_t *vblanktime); > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > > struct drm_pending_vblank_event *e); > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > >
On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > On Mon, 20 Feb 2023 07:55:41 -0800 > Rob Clark <robdclark@gmail.com> wrote: > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > atomic update is waiting on. > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > --- > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > include/drm/drm_vblank.h | 1 + > > > > 2 files changed, 33 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > } > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > +/** > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > + * > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > + * vblank and frame duration > > > > > > Hi, > > > > > > for VRR this targets the highest frame rate possible for the current > > > VRR mode, right? > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > I don't know. :-) At least for i915 this will give you the maximum frame duration. Also this does not calculate the the start of vblank, it calculates the start of active video. > > You need a number of clock cycles in addition to the clock frequency, > and that could still be minimum, maximum, the last realized one, ... > > VRR works by adjusting the front porch length IIRC. > > > Thanks, > pq > > > BR, > > -R > > > > > > > > > > Thanks, > > > pq > > > > > > > + */ > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > > > +{ > > > > + unsigned int pipe = drm_crtc_index(crtc); > > > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > > > + u64 count; > > > > + > > > > + if (!vblank->framedur_ns) > > > > + return -EINVAL; > > > > + > > > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > > > + > > > > + /* > > > > + * If we don't get a valid count, then we probably also don't > > > > + * have a valid time: > > > > + */ > > > > + if (!count) > > > > + return -EINVAL; > > > > + > > > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > > > + > > > > + return 0; > > > > +} > > > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > > > + > > > > static void send_vblank_event(struct drm_device *dev, > > > > struct drm_pending_vblank_event *e, > > > > u64 seq, ktime_t now) > > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > > > --- a/include/drm/drm_vblank.h > > > > +++ b/include/drm/drm_vblank.h > > > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > ktime_t *vblanktime); > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > > > struct drm_pending_vblank_event *e); > > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > > > >
On Tue, 21 Feb 2023 15:01:35 +0200 Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > On Mon, 20 Feb 2023 07:55:41 -0800 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > atomic update is waiting on. > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > --- > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > include/drm/drm_vblank.h | 1 + > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > } > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > +/** > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > + * > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > + * vblank and frame duration > > > > > > > > Hi, > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > VRR mode, right? > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > I don't know. :-) > > At least for i915 this will give you the maximum frame > duration. Really maximum duration? So minimum VRR frequency? > Also this does not calculate the the start of vblank, it > calculates the start of active video. Oh indeed, so it's too late. What one would actually need for the deadline is the driver's deadline to present for the immediately next start of active video. And with VRR that should probably aim for the maximum frame frequency, not minimum? Thanks, pq > > > > > You need a number of clock cycles in addition to the clock frequency, > > and that could still be minimum, maximum, the last realized one, ... > > > > VRR works by adjusting the front porch length IIRC. > > > > > > Thanks, > > pq > > > > > BR, > > > -R > > > > > > > > > > > > > > Thanks, > > > > pq > > > > > > > > > + */ > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > > > > +{ > > > > > + unsigned int pipe = drm_crtc_index(crtc); > > > > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > > > > + u64 count; > > > > > + > > > > > + if (!vblank->framedur_ns) > > > > > + return -EINVAL; > > > > > + > > > > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > > > > + > > > > > + /* > > > > > + * If we don't get a valid count, then we probably also don't > > > > > + * have a valid time: > > > > > + */ > > > > > + if (!count) > > > > > + return -EINVAL; > > > > > + > > > > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > > > > + > > > > > + return 0; > > > > > +} > > > > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > > > > + > > > > > static void send_vblank_event(struct drm_device *dev, > > > > > struct drm_pending_vblank_event *e, > > > > > u64 seq, ktime_t now) > > > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > > > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > > > > --- a/include/drm/drm_vblank.h > > > > > +++ b/include/drm/drm_vblank.h > > > > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > > > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > > > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > ktime_t *vblanktime); > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > > > > struct drm_pending_vblank_event *e); > > > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > > > > > > > > >
On Tue, Feb 21, 2023 at 03:11:33PM +0200, Pekka Paalanen wrote: > On Tue, 21 Feb 2023 15:01:35 +0200 > Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > atomic update is waiting on. > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > --- > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > } > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > +/** > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > + * > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > + * vblank and frame duration > > > > > > > > > > Hi, > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > VRR mode, right? > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > I don't know. :-) > > > > At least for i915 this will give you the maximum frame > > duration. > > Really maximum duration? So minimum VRR frequency? Yes. Doing otherwise would complicate the actual timestamp calculation even further. The actual timestamps i915 generates will however match the start of active video, regardless of how long vblank was extended. The only exception might be if you query the timestamp during vblank but VRR exit has not yet been triggered, ie. not commit has been made during the frame. In that case the timestamp will correspond to the max frame duration, which may or may not end up being the case. Depends totally whether a commit will still happen during the vblank to trigger an early vblank exit. > > > Also this does not calculate the the start of vblank, it > > calculates the start of active video. > > Oh indeed, so it's too late. What one would actually need for the > deadline is the driver's deadline to present for the immediately next > start of active video. > > And with VRR that should probably aim for the maximum frame frequency, > not minimum? Yeah, max frame rate seems like the easiest thing to use there. The other option might be some average value based on recent history, but figuring tht out would seem like a lot more work.
On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > On Mon, 20 Feb 2023 07:55:41 -0800 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > atomic update is waiting on. > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > --- > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > include/drm/drm_vblank.h | 1 + > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > } > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > +/** > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > + * > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > + * vblank and frame duration > > > > > > > > Hi, > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > VRR mode, right? > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > I don't know. :-) > > At least for i915 this will give you the maximum frame > duration. I suppose one could argue that maximum frame duration is the actual deadline. Anything less is just moar fps, but not going to involve stalling until vblank N+1, AFAIU > Also this does not calculate the the start of vblank, it > calculates the start of active video. Probably something like end of previous frame's video.. might not be _exactly_ correct (because some buffering involved), but OTOH on the GPU side, I expect the driver to set a timer for a few ms or so before the deadline. So there is some wiggle room. BR, -R > > > > You need a number of clock cycles in addition to the clock frequency, > > and that could still be minimum, maximum, the last realized one, ... > > > > VRR works by adjusting the front porch length IIRC. > > > > > > Thanks, > > pq > > > > > BR, > > > -R > > > > > > > > > > > > > > Thanks, > > > > pq > > > > > > > > > + */ > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > > > > +{ > > > > > + unsigned int pipe = drm_crtc_index(crtc); > > > > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > > > > + u64 count; > > > > > + > > > > > + if (!vblank->framedur_ns) > > > > > + return -EINVAL; > > > > > + > > > > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > > > > + > > > > > + /* > > > > > + * If we don't get a valid count, then we probably also don't > > > > > + * have a valid time: > > > > > + */ > > > > > + if (!count) > > > > > + return -EINVAL; > > > > > + > > > > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > > > > + > > > > > + return 0; > > > > > +} > > > > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > > > > + > > > > > static void send_vblank_event(struct drm_device *dev, > > > > > struct drm_pending_vblank_event *e, > > > > > u64 seq, ktime_t now) > > > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > > > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > > > > --- a/include/drm/drm_vblank.h > > > > > +++ b/include/drm/drm_vblank.h > > > > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > > > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > > > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > ktime_t *vblanktime); > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > > > > struct drm_pending_vblank_event *e); > > > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > > > > > > > > > > -- > Ville Syrjälä > Intel
On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > On Mon, 20 Feb 2023 07:55:41 -0800 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > atomic update is waiting on. > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > --- > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > include/drm/drm_vblank.h | 1 + > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > } > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > +/** > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > + * > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > + * vblank and frame duration > > > > > > > > Hi, > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > VRR mode, right? > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > I don't know. :-) > > At least for i915 this will give you the maximum frame > duration. > > Also this does not calculate the the start of vblank, it > calculates the start of active video. AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); framedur = ns_to_ktime(vblank->framedur_ns); *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); ? BR, -R > > > > > You need a number of clock cycles in addition to the clock frequency, > > and that could still be minimum, maximum, the last realized one, ... > > > > VRR works by adjusting the front porch length IIRC. > > > > > > Thanks, > > pq > > > > > BR, > > > -R > > > > > > > > > > > > > > Thanks, > > > > pq > > > > > > > > > + */ > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > > > > +{ > > > > > + unsigned int pipe = drm_crtc_index(crtc); > > > > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > > > > + u64 count; > > > > > + > > > > > + if (!vblank->framedur_ns) > > > > > + return -EINVAL; > > > > > + > > > > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > > > > + > > > > > + /* > > > > > + * If we don't get a valid count, then we probably also don't > > > > > + * have a valid time: > > > > > + */ > > > > > + if (!count) > > > > > + return -EINVAL; > > > > > + > > > > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > > > > + > > > > > + return 0; > > > > > +} > > > > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > > > > + > > > > > static void send_vblank_event(struct drm_device *dev, > > > > > struct drm_pending_vblank_event *e, > > > > > u64 seq, ktime_t now) > > > > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > > > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > > > > --- a/include/drm/drm_vblank.h > > > > > +++ b/include/drm/drm_vblank.h > > > > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > > > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > > > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > ktime_t *vblanktime); > > > > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > > > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > > > > struct drm_pending_vblank_event *e); > > > > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > > > > > > > > > > -- > Ville Syrjälä > Intel
On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > atomic update is waiting on. > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > --- > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > } > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > +/** > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > + * > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > + * vblank and frame duration > > > > > > > > > > Hi, > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > VRR mode, right? > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > I don't know. :-) > > > > At least for i915 this will give you the maximum frame > > duration. > > > > Also this does not calculate the the start of vblank, it > > calculates the start of active video. > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > framedur = ns_to_ktime(vblank->framedur_ns); > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); Something like this should work: vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal deadline = vblanktime + vblank_start That would be the expected time when the next start of vblank happens.
On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote: > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > } > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > +/** > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > + * > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > + * vblank and frame duration > > > > > > > > > > > > Hi, > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > I don't know. :-) > > > > > > At least for i915 this will give you the maximum frame > > > duration. > > > > > > Also this does not calculate the the start of vblank, it > > > calculates the start of active video. > > > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > > framedur = ns_to_ktime(vblank->framedur_ns); > > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); > > Something like this should work: > vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal > deadline = vblanktime + vblank_start > > That would be the expected time when the next start of vblank > happens. Except that drm_vblank_count_and_time() will give you the last sampled timestamp, which may be long ago in the past. Would need to add an _accurate version of that if we want to be guaranteed a fresh sample.
On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote: > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > --- > > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > > } > > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > > > +/** > > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > > + * > > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > > + * vblank and frame duration > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > > > I don't know. :-) > > > > > > > > At least for i915 this will give you the maximum frame > > > > duration. > > > > > > > > Also this does not calculate the the start of vblank, it > > > > calculates the start of active video. > > > > > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > > > > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > > > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > > > framedur = ns_to_ktime(vblank->framedur_ns); > > > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); > > > > Something like this should work: > > vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal > > deadline = vblanktime + vblank_start > > > > That would be the expected time when the next start of vblank > > happens. > > Except that drm_vblank_count_and_time() will give you the last > sampled timestamp, which may be long ago in the past. Would > need to add an _accurate version of that if we want to be > guaranteed a fresh sample. IIRC the only time we wouldn't have a fresh sample is if the screen has been idle for some time? In which case, I think that doesn't matter. BR, -R > > -- > Ville Syrjälä > Intel
On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote: > On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote: > > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > > --- > > > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > > > } > > > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > > > + * > > > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > > > + * vblank and frame duration > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > > > > > I don't know. :-) > > > > > > > > > > At least for i915 this will give you the maximum frame > > > > > duration. > > > > > > > > > > Also this does not calculate the the start of vblank, it > > > > > calculates the start of active video. > > > > > > > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > > > > > > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > > > > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > > > > framedur = ns_to_ktime(vblank->framedur_ns); > > > > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); > > > > > > Something like this should work: > > > vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal > > > deadline = vblanktime + vblank_start > > > > > > That would be the expected time when the next start of vblank > > > happens. > > > > Except that drm_vblank_count_and_time() will give you the last > > sampled timestamp, which may be long ago in the past. Would > > need to add an _accurate version of that if we want to be > > guaranteed a fresh sample. > > IIRC the only time we wouldn't have a fresh sample is if the screen > has been idle for some time? IIRC "some time" == 1 idle frame, for any driver that sets vblank_disable_immediate. > In which case, I think that doesn't > matter. > > BR, > -R > > > > > -- > > Ville Syrjälä > > Intel
On Tue, Feb 21, 2023 at 2:46 PM Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote: > > On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > > > > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote: > > > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > > > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > > > --- > > > > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > > > > } > > > > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > > > > + * > > > > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > > > > + * vblank and frame duration > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > > > > > > > I don't know. :-) > > > > > > > > > > > > At least for i915 this will give you the maximum frame > > > > > > duration. > > > > > > > > > > > > Also this does not calculate the the start of vblank, it > > > > > > calculates the start of active video. > > > > > > > > > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > > > > > > > > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > > > > > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > > > > > framedur = ns_to_ktime(vblank->framedur_ns); > > > > > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); > > > > > > > > Something like this should work: > > > > vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal > > > > deadline = vblanktime + vblank_start > > > > > > > > That would be the expected time when the next start of vblank > > > > happens. > > > > > > Except that drm_vblank_count_and_time() will give you the last > > > sampled timestamp, which may be long ago in the past. Would > > > need to add an _accurate version of that if we want to be > > > guaranteed a fresh sample. > > > > IIRC the only time we wouldn't have a fresh sample is if the screen > > has been idle for some time? > > IIRC "some time" == 1 idle frame, for any driver that sets > vblank_disable_immediate. > hmm, ok so it should be still good down to 30fps ;-) I thought we calculated based on frame # and line # on hw that supported that? But it's been a while since looking at vblank code BR, -R > > In which case, I think that doesn't > > matter. > > > > BR, > > -R > > > > > > > > -- > > > Ville Syrjälä > > > Intel > > -- > Ville Syrjälä > Intel
On Tue, Feb 21, 2023 at 3:20 PM Rob Clark <robdclark@gmail.com> wrote: > > On Tue, Feb 21, 2023 at 2:46 PM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Feb 21, 2023 at 02:28:10PM -0800, Rob Clark wrote: > > > On Tue, Feb 21, 2023 at 1:48 PM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > On Tue, Feb 21, 2023 at 11:39:40PM +0200, Ville Syrjälä wrote: > > > > > On Tue, Feb 21, 2023 at 11:54:55AM -0800, Rob Clark wrote: > > > > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > > > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > --- > > > > > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > > > > > } > > > > > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > > > > > > > > > +/** > > > > > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > > > > > + * > > > > > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > > > > > + * vblank and frame duration > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > > > > > > > > > I don't know. :-) > > > > > > > > > > > > > > At least for i915 this will give you the maximum frame > > > > > > > duration. > > > > > > > > > > > > > > Also this does not calculate the the start of vblank, it > > > > > > > calculates the start of active video. > > > > > > > > > > > > AFAIU, vsync_end/vsync_start are in units of line, so I could do something like: > > > > > > > > > > > > vsync_lines = vblank->hwmode.vsync_end - vblank->hwmode.vsync_start; > > > > > > vsyncdur = ns_to_ktime(vblank->linedur_ns * vsync_lines); > > > > > > framedur = ns_to_ktime(vblank->framedur_ns); > > > > > > *vblanktime = ktime_add(*vblanktime, ktime_sub(framedur, vsyncdur)); > > > > > > > > > > Something like this should work: > > > > > vblank_start = framedur_ns * crtc_vblank_start / crtc_vtotal > > > > > deadline = vblanktime + vblank_start > > > > > > > > > > That would be the expected time when the next start of vblank > > > > > happens. > > > > > > > > Except that drm_vblank_count_and_time() will give you the last > > > > sampled timestamp, which may be long ago in the past. Would > > > > need to add an _accurate version of that if we want to be > > > > guaranteed a fresh sample. > > > > > > IIRC the only time we wouldn't have a fresh sample is if the screen > > > has been idle for some time? > > > > IIRC "some time" == 1 idle frame, for any driver that sets > > vblank_disable_immediate. > > > > hmm, ok so it should be still good down to 30fps ;-) > > I thought we calculated based on frame # and line # on hw that > supported that? But it's been a while since looking at vblank code looks like drm_get_last_vbltimestamp() is what I want.. > BR, > -R > > > > In which case, I think that doesn't > > > matter. > > > > > > BR, > > > -R > > > > > > > > > > > -- > > > > Ville Syrjälä > > > > Intel > > > > -- > > Ville Syrjälä > > Intel
On Tue, 21 Feb 2023 09:50:20 -0800 Rob Clark <robdclark@gmail.com> wrote: > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > <ville.syrjala@linux.intel.com> wrote: > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > atomic update is waiting on. > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > --- > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > } > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > +/** > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > + * > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > + * vblank and frame duration > > > > > > > > > > Hi, > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > VRR mode, right? > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > I don't know. :-) > > > > At least for i915 this will give you the maximum frame > > duration. > > I suppose one could argue that maximum frame duration is the actual > deadline. Anything less is just moar fps, but not going to involve > stalling until vblank N+1, AFAIU > > > Also this does not calculate the the start of vblank, it > > calculates the start of active video. > > Probably something like end of previous frame's video.. might not be > _exactly_ correct (because some buffering involved), but OTOH on the > GPU side, I expect the driver to set a timer for a few ms or so before > the deadline. So there is some wiggle room. The vblank timestamp is defined to be the time of the first active pixel of the frame in the video signal. At least that's the one that UAPI carries (when not tearing?). It is not the start of vblank period. With VRR, the front porch before the first active pixel can be multiple milliseconds. The difference between 144 Hz and 60 Hz is 9.7 ms for example. Thanks, pq
On 2023-02-18 16:15, Rob Clark wrote: > From: Rob Clark <robdclark@chromium.org> > > Will be used in the next commit to set a deadline on fences that an > atomic update is waiting on. > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > include/drm/drm_vblank.h | 1 + > 2 files changed, 33 insertions(+) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 2ff31717a3de..caf25ebb34c5 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > } > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > +/** > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > + * @crtc: the crtc for which to calculate next vblank time > + * @vblanktime: pointer to time to receive the next vblank timestamp. > + * > + * Calculate the expected time of the next vblank based on time of previous > + * vblank and frame duration > + */ > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > +{ > + unsigned int pipe = drm_crtc_index(crtc); > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > + u64 count; > + > + if (!vblank->framedur_ns) > + return -EINVAL; > + > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > + > + /* > + * If we don't get a valid count, then we probably also don't > + * have a valid time: > + */ > + if (!count) > + return -EINVAL; > + > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); I'd rather this not do any arithmetic, i.e. add, and simply return the calculated remaining time, i.e. time left--so instead of add, it would simply assign the remaining time, and possibly rename the vblanktime to something like "time_to_vblank." Changing the top comment to "calculate the time remaining to the next vblank".
On Wed, Feb 22, 2023 at 1:57 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > On Tue, 21 Feb 2023 09:50:20 -0800 > Rob Clark <robdclark@gmail.com> wrote: > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > <ville.syrjala@linux.intel.com> wrote: > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > --- > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > } > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > +/** > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > + * > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > + * vblank and frame duration > > > > > > > > > > > > Hi, > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > I don't know. :-) > > > > > > At least for i915 this will give you the maximum frame > > > duration. > > > > I suppose one could argue that maximum frame duration is the actual > > deadline. Anything less is just moar fps, but not going to involve > > stalling until vblank N+1, AFAIU > > > > > Also this does not calculate the the start of vblank, it > > > calculates the start of active video. > > > > Probably something like end of previous frame's video.. might not be > > _exactly_ correct (because some buffering involved), but OTOH on the > > GPU side, I expect the driver to set a timer for a few ms or so before > > the deadline. So there is some wiggle room. > > The vblank timestamp is defined to be the time of the first active > pixel of the frame in the video signal. At least that's the one that > UAPI carries (when not tearing?). It is not the start of vblank period. > > With VRR, the front porch before the first active pixel can be multiple > milliseconds. The difference between 144 Hz and 60 Hz is 9.7 ms for > example. What we really want is the deadline for the hw to latch for the next frame.. which as Ville pointed out is definitely before the end of vblank. Honestly this sort of feature is a lot more critical for the non-VRR case, and VRR is kind of a minority edge case. So I'd prefer not to get too hung up on VRR. If there is an easy way for the helpers to detect VRR, I'd be perfectly fine not setting a deadline hint in that case, and let someone who actually has a VRR display figure out how to handle that case. BR, -R
On Wed, Feb 22, 2023 at 2:37 AM Luben Tuikov <luben.tuikov@amd.com> wrote: > > On 2023-02-18 16:15, Rob Clark wrote: > > From: Rob Clark <robdclark@chromium.org> > > > > Will be used in the next commit to set a deadline on fences that an > > atomic update is waiting on. > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > --- > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > include/drm/drm_vblank.h | 1 + > > 2 files changed, 33 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index 2ff31717a3de..caf25ebb34c5 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > } > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > +/** > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > + * @crtc: the crtc for which to calculate next vblank time > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > + * > > + * Calculate the expected time of the next vblank based on time of previous > > + * vblank and frame duration > > + */ > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) > > +{ > > + unsigned int pipe = drm_crtc_index(crtc); > > + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; > > + u64 count; > > + > > + if (!vblank->framedur_ns) > > + return -EINVAL; > > + > > + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); > > + > > + /* > > + * If we don't get a valid count, then we probably also don't > > + * have a valid time: > > + */ > > + if (!count) > > + return -EINVAL; > > + > > + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); > > I'd rather this not do any arithmetic, i.e. add, and simply return the calculated > remaining time, i.e. time left--so instead of add, it would simply assign > the remaining time, and possibly rename the vblanktime to something like "time_to_vblank." > Note that since I sent the last iteration, I've renamed it to drm_crtc_next_vblank_start(). I would prefer to keep the arithmetic, because I have another use for this helper in drm/msm (for async/cursor updates, where we want to set an hrtimer for start of vblank). It is a bit off the topic of this series, but I can include the patch when I repost. BR, -R > Changing the top comment to "calculate the time remaining to the next vblank". > -- > Regards, > Luben > > > + > > + return 0; > > +} > > +EXPORT_SYMBOL(drm_crtc_next_vblank_time); > > + > > static void send_vblank_event(struct drm_device *dev, > > struct drm_pending_vblank_event *e, > > u64 seq, ktime_t now) > > diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h > > index 733a3e2d1d10..a63bc2c92f3c 100644 > > --- a/include/drm/drm_vblank.h > > +++ b/include/drm/drm_vblank.h > > @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); > > u64 drm_crtc_vblank_count(struct drm_crtc *crtc); > > u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > ktime_t *vblanktime); > > +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); > > void drm_crtc_send_vblank_event(struct drm_crtc *crtc, > > struct drm_pending_vblank_event *e); > > void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, >
On Wed, Feb 22, 2023 at 07:44:42AM -0800, Rob Clark wrote: > On Wed, Feb 22, 2023 at 1:57 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > On Tue, 21 Feb 2023 09:50:20 -0800 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > On Tue, Feb 21, 2023 at 5:01 AM Ville Syrjälä > > > <ville.syrjala@linux.intel.com> wrote: > > > > > > > > On Tue, Feb 21, 2023 at 10:45:51AM +0200, Pekka Paalanen wrote: > > > > > On Mon, 20 Feb 2023 07:55:41 -0800 > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > On Mon, Feb 20, 2023 at 1:08 AM Pekka Paalanen <ppaalanen@gmail.com> wrote: > > > > > > > > > > > > > > On Sat, 18 Feb 2023 13:15:53 -0800 > > > > > > > Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > > > > > > > > From: Rob Clark <robdclark@chromium.org> > > > > > > > > > > > > > > > > Will be used in the next commit to set a deadline on fences that an > > > > > > > > atomic update is waiting on. > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > > > > > > --- > > > > > > > > drivers/gpu/drm/drm_vblank.c | 32 ++++++++++++++++++++++++++++++++ > > > > > > > > include/drm/drm_vblank.h | 1 + > > > > > > > > 2 files changed, 33 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > > > > > > index 2ff31717a3de..caf25ebb34c5 100644 > > > > > > > > --- a/drivers/gpu/drm/drm_vblank.c > > > > > > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > > > > > > @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, > > > > > > > > } > > > > > > > > EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); > > > > > > > > > > > > > > > > +/** > > > > > > > > + * drm_crtc_next_vblank_time - calculate the time of the next vblank > > > > > > > > + * @crtc: the crtc for which to calculate next vblank time > > > > > > > > + * @vblanktime: pointer to time to receive the next vblank timestamp. > > > > > > > > + * > > > > > > > > + * Calculate the expected time of the next vblank based on time of previous > > > > > > > > + * vblank and frame duration > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > for VRR this targets the highest frame rate possible for the current > > > > > > > VRR mode, right? > > > > > > > > > > > > > > > > > > > It is based on vblank->framedur_ns which is in turn based on > > > > > > mode->crtc_clock. Presumably for VRR that ends up being a maximum? > > > > > > > > > > I don't know. :-) > > > > > > > > At least for i915 this will give you the maximum frame > > > > duration. > > > > > > I suppose one could argue that maximum frame duration is the actual > > > deadline. Anything less is just moar fps, but not going to involve > > > stalling until vblank N+1, AFAIU > > > > > > > Also this does not calculate the the start of vblank, it > > > > calculates the start of active video. > > > > > > Probably something like end of previous frame's video.. might not be > > > _exactly_ correct (because some buffering involved), but OTOH on the > > > GPU side, I expect the driver to set a timer for a few ms or so before > > > the deadline. So there is some wiggle room. > > > > The vblank timestamp is defined to be the time of the first active > > pixel of the frame in the video signal. At least that's the one that > > UAPI carries (when not tearing?). It is not the start of vblank period. > > > > With VRR, the front porch before the first active pixel can be multiple > > milliseconds. The difference between 144 Hz and 60 Hz is 9.7 ms for > > example. > > What we really want is the deadline for the hw to latch for the next > frame.. which as Ville pointed out is definitely before the end of > vblank. > > Honestly this sort of feature is a lot more critical for the non-VRR > case, and VRR is kind of a minority edge case. So I'd prefer not to > get too hung up on VRR. If there is an easy way for the helpers to > detect VRR, I'd be perfectly fine not setting a deadline hint in that > case, and let someone who actually has a VRR display figure out how to > handle that case. The formula I gave you earlier works for both VRR and non-VRR.
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 2ff31717a3de..caf25ebb34c5 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -980,6 +980,38 @@ u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, } EXPORT_SYMBOL(drm_crtc_vblank_count_and_time); +/** + * drm_crtc_next_vblank_time - calculate the time of the next vblank + * @crtc: the crtc for which to calculate next vblank time + * @vblanktime: pointer to time to receive the next vblank timestamp. + * + * Calculate the expected time of the next vblank based on time of previous + * vblank and frame duration + */ +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime) +{ + unsigned int pipe = drm_crtc_index(crtc); + struct drm_vblank_crtc *vblank = &crtc->dev->vblank[pipe]; + u64 count; + + if (!vblank->framedur_ns) + return -EINVAL; + + count = drm_vblank_count_and_time(crtc->dev, pipe, vblanktime); + + /* + * If we don't get a valid count, then we probably also don't + * have a valid time: + */ + if (!count) + return -EINVAL; + + *vblanktime = ktime_add(*vblanktime, ns_to_ktime(vblank->framedur_ns)); + + return 0; +} +EXPORT_SYMBOL(drm_crtc_next_vblank_time); + static void send_vblank_event(struct drm_device *dev, struct drm_pending_vblank_event *e, u64 seq, ktime_t now) diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h index 733a3e2d1d10..a63bc2c92f3c 100644 --- a/include/drm/drm_vblank.h +++ b/include/drm/drm_vblank.h @@ -230,6 +230,7 @@ bool drm_dev_has_vblank(const struct drm_device *dev); u64 drm_crtc_vblank_count(struct drm_crtc *crtc); u64 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc, ktime_t *vblanktime); +int drm_crtc_next_vblank_time(struct drm_crtc *crtc, ktime_t *vblanktime); void drm_crtc_send_vblank_event(struct drm_crtc *crtc, struct drm_pending_vblank_event *e); void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,