public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
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

  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