From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jason-JH Lin <jason-jh.lin@mediatek.com>
Cc: igt-dev@lists.freedesktop.org,
Karthik B S <karthik.b.s@intel.com>,
Swati Sharma <swati2.sharma@intel.com>,
Jani <jani.nikula@intel.com>, Jeevan <jeevan.b@intel.com>,
Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Fei Shao <fshao@chromium.org>,
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>,
Bhanuprakash Modem <bhanuprakash.modem@gmail.com>,
Paul-PL Chen <paul-pl.chen@mediatek.com>,
Nancy Lin <nancy.lin@mediatek.com>,
Singo Chang <singo.chang@mediatek.com>,
Gil Dekel <gildekel@google.com>, Yacoub <markyacoub@chromium.org>,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH i-g-t v2] tests/kms_setmode: Relax vblank timing tolerance from 1 scanline to 1%
Date: Thu, 16 Apr 2026 18:29:15 +0300 [thread overview]
Message-ID: <aeEAS30Z9hFW8CSc@intel.com> (raw)
In-Reply-To: <aeD5qtEo0h4KKDu4@intel.com>
On Thu, Apr 16, 2026 at 06:00:58PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 16, 2026 at 10:45:28PM +0800, Jason-JH Lin wrote:
> > The original check_timings() validation required vblank intervals to be
> > within 1 scanline (~15us for 1080p60) which is overly strict and causes
> > false failures due to userspace measurement overhead.
> >
> > Changes:
> > - Keep original strict checks (1 scanline, 1.718 sigma) as warnings only
> > - Add relaxed validation with 1% relative tolerance for pass/fail
> > - Use 3 sigma threshold (99.7% confidence) instead of 1.718 sigma (90%)
> >
> > Rationale:
> > Hardware specs (VESA/HDMI/DP) allow ±0.5% pixel clock tolerance, which
> > translates to ±0.5% frame time due to inverse relationship. However,
> > userspace measurement via read() syscall adds ~0.3-0.5% overhead from:
>
> read() overhead is irrelevant here. This is measuring the accuracy
> of the kernel generated vblank event timestamps. If you are having
> problems with this then that would indicate your kernel driver isn't
> generating particularly good timestamps, or it's using a dotclock that
> doesn't quite match what userspace specified originally.
>
> > - Interrupt latency and scheduling delays (5-50 us)
> > - System call overhead (1-5 us)
> > - Variable delays depending on system load
> >
> > Total tolerance: ±0.5% (hardware) + ~0.5% (software) = ±1.0%
> >
> > This makes the test ~11x more tolerant while still detecting real timing
> > issues and aligning with industry hardware specifications.
> >
> > Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
> > Suggested-by: Jeevain B <jeevan.b@intel.com>
> > ---
> > tests/kms_setmode.c | 71 +++++++++++++++++++++++++++++++++++++--------
> > 1 file changed, 59 insertions(+), 12 deletions(-)
> >
> > diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> > index 1f2849bc26cf..b452f8a9e997 100644
> > --- a/tests/kms_setmode.c
> > +++ b/tests/kms_setmode.c
> > @@ -495,6 +495,7 @@ static bool check_timings(int crtc_idx, const drmModeModeInfo *kmode)
> > double mean;
> > double stddev;
> > int n;
> > + bool strict_failed = false;
> >
> > memset(&wait, 0, sizeof(wait));
> > wait.request.type = kmstest_get_vbl_flag(crtc_idx);
> > @@ -563,10 +564,9 @@ static bool check_timings(int crtc_idx, const drmModeModeInfo *kmode)
> >
> > /* 99.7% samples within one scanline on each side of mean */
> > if (accuracy >= line_time(kmode)) {
> > - igt_info("vblank accuracy (%.3fus, %.1f%%) worse than a scanline (%.3fus)\n",
> > - accuracy, 100 * accuracy / mean, line_time(kmode));
> > -
> > - return false;
> > + igt_warn("vblank accuracy (%.3fus, %.1f%%) worse than a scanline (%.3fus)\n",
> > + accuracy, 100 * accuracy / mean, line_time(kmode));
> > + strict_failed = true;
Failing this would indicate the driver isn't generating particularly
good timestamps.
> > }
> >
> > /* At least 90% of frame times fall within the one scanline on each
> > @@ -591,14 +591,61 @@ static bool check_timings(int crtc_idx, const drmModeModeInfo *kmode)
> > * https://en.wikipedia.org/wiki/Standard_deviation#Rules_for_normally_distributed_data
> > */
> > if (fabs(mean - expected) >= max(line_time(kmode), 1.718 * stddev)) {
And assuming the timestamps were good, failing this would indicate the
actual timings don't quite match what userspace specified (eg. dotclock
could be a bit off). I suppose we should allow that VESA specified
.5% error here.
> > - igt_info("vblank interval differs from modeline! expected %.1fus, "
> > - "measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma, %.1f scanlines)\n",
> > - expected, mean, stddev,
> > - fabs(mean - expected),
> > - fabs(mean - expected) / stddev,
> > - fabs(mean - expected) / line_time(kmode));
> > -
> > - return false;
> > + igt_warn("vblank interval differs from modeline! expected %.1fus, "
> > + "measured %1.fus +- %.3fus, difference %.1fus "
> > + "(%.1f sigma, %.1f scanlines)\n",
> > + expected, mean, stddev,
> > + fabs(mean - expected),
> > + fabs(mean - expected) / stddev,
> > + fabs(mean - expected) / line_time(kmode));
> > + strict_failed = true;
> > + }
> > +
> > + if (strict_failed) {
> > + /* Relaxed validation: 1% relative tolerance for accuracy and deviation
> > + *
> > + * Hardware specifications (VESA/HDMI/DP) allow ±0.5% pixel clock tolerance.
> > + * Since frame_time = (htotal × vtotal) / pixel_clock, the relationship is
> > + * inverse: ±0.5% pixel clock → ±0.5% frame time (in opposite direction).
> > + *
> > + * However, userspace measurement introduces additional overhead (~0.3-0.5%):
> > + * - Interrupt latency and scheduling delays (5-50 μs)
> > + * - System call overhead for read() (1-5 μs)
> > + * - Variable delays depending on system load
> > + *
> > + * Total tolerance: ±0.5% (hardware) + ~0.5% (software) ≈ ±1.0%
> > + *
> > + * For stricter validation matching hardware spec only, use 0.005 (0.5%),
> > + * but expect potential false failures due to measurement noise.
> > + */
> > + double tolerance_pct = 0.01; /* 1% tolerance */
> > + double tolerance_us = expected * tolerance_pct;
> > + double relative_accuracy = accuracy / expected;
> > +
> > + /* Check 1: 99.7% samples within 1% of the mean */
> > + if (accuracy >= tolerance_us) {
> > + igt_info("FAIL: vblank accuracy (%.3fus, %.2f%%) exceeds 1%% tolerance "
> > + "(%.3fus)\n",
> > + accuracy, 100 * relative_accuracy, tolerance_us);
> > + return false;
> > + }
> > +
> > + /* Check 2: Mean within 1% of expected, or within 3 sigma (99.7% confidence) */
> > + if (fabs(mean - expected) >= max(tolerance_us, 3.0 * stddev)) {
> > + igt_info("FAIL: vblank interval differs from expected! expected %.1fus, "
> > + "measured %.1fus +- %.3fus, difference %.1fus "
> > + "(%.1f sigma, %.2f%%), "
> > + "exceeds 1%% tolerance or 3-sigma threshold\n",
> > + expected, mean, stddev,
> > + fabs(mean - expected),
> > + fabs(mean - expected) / stddev,
> > + 100 * fabs(mean - expected) / expected);
> > + return false;
> > + }
> > +
> > + igt_info("Passed relaxed validation (strict failed)\n");
> > + } else {
> > + igt_info("Passed strict validation\n");
> > }
> >
> > return true;
> > --
> > 2.43.0
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-04-16 15:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 14:45 [PATCH i-g-t v2] tests/kms_setmode: Relax vblank timing tolerance from 1 scanline to 1% Jason-JH Lin
2026-04-16 15:00 ` Ville Syrjälä
2026-04-16 15:29 ` Ville Syrjälä [this message]
2026-04-17 8:50 ` Jason-JH Lin (林睿祥)
2026-04-17 0:04 ` ✓ Xe.CI.BAT: success for tests/kms_setmode: Relax vblank timing tolerance from 1 scanline to 1% (rev2) Patchwork
2026-04-17 0:08 ` ✗ i915.CI.BAT: failure " Patchwork
2026-04-17 2:31 ` ✗ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aeEAS30Z9hFW8CSc@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=bhanuprakash.modem@gmail.com \
--cc=fshao@chromium.org \
--cc=gildekel@google.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=jason-jh.lin@mediatek.com \
--cc=jeevan.b@intel.com \
--cc=juhapekka.heikkila@gmail.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=karthik.b.s@intel.com \
--cc=markyacoub@chromium.org \
--cc=nancy.lin@mediatek.com \
--cc=paul-pl.chen@mediatek.com \
--cc=singo.chang@mediatek.com \
--cc=swati2.sharma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox