From: Jason-JH Lin <jason-jh.lin@mediatek.com>
To: <igt-dev@lists.freedesktop.org>,
Karthik B S <karthik.b.s@intel.com>,
Swati Sharma <swati2.sharma@intel.com>,
Kamil Konieczny <kamil.konieczny@linux.intel.com>,
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>,
Bhanuprakash Modem <bhanuprakash.modem@gmail.com>,
Fei Shao <fshao@chromium.org>
Cc: Jani <jani.nikula@intel.com>,
Jason-JH Lin <jason-jh.lin@mediatek.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: [PATCH i-g-t] tests/kms_setmode: Relax vblank timing tolerance from 1 scanline to 1%
Date: Thu, 16 Apr 2026 10:53:56 +0800 [thread overview]
Message-ID: <20260416025408.2924216-1-jason-jh.lin@mediatek.com> (raw)
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:
- 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>
---
tests/kms_setmode.c | 48 ++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 1f2849bc26cf..30ab53fef47c 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -563,10 +563,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",
+ igt_warn("vblank accuracy (%.3fus, %.1f%%) worse than a scanline (%.3fus) - "
+ "strict check failed but continuing with relaxed validation\n",
accuracy, 100 * accuracy / mean, line_time(kmode));
-
- return false;
}
/* At least 90% of frame times fall within the one scanline on each
@@ -591,16 +590,55 @@ 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)) {
- igt_info("vblank interval differs from modeline! expected %.1fus, "
- "measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma, %.1f scanlines)\n",
+ igt_warn("vblank interval differs from modeline! expected %.1fus, "
+ "measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma, %.1f scanlines) - "
+ "strict check failed but continuing with relaxed validation\n",
expected, mean, stddev,
fabs(mean - expected),
fabs(mean - expected) / stddev,
fabs(mean - expected) / line_time(kmode));
+ }
+
+ /* 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("Timing validation passed (within 1%% tolerance)\n");
return true;
}
--
2.43.0
next reply other threads:[~2026-04-16 2:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 2:53 Jason-JH Lin [this message]
2026-04-16 4:11 ` ✓ i915.CI.BAT: success for tests/kms_setmode: Relax vblank timing tolerance from 1 scanline to 1% Patchwork
2026-04-16 4:25 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-16 5:56 ` [PATCH i-g-t] " B, Jeevan
2026-04-16 8:12 ` Jason-JH Lin (林睿祥)
2026-04-16 6:50 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-04-16 14:32 ` ✗ i915.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=20260416025408.2924216-1-jason-jh.lin@mediatek.com \
--to=jason-jh.lin@mediatek.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=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