public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: igt-dev@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org, Chris Wilson <chris@chris-wilson.co.uk>
Subject: [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric
Date: Fri,  8 May 2020 15:56:30 +0200	[thread overview]
Message-ID: <20200508135631.8099-2-janusz.krzysztofik@linux.intel.com> (raw)
In-Reply-To: <20200508135631.8099-1-janusz.krzysztofik@linux.intel.com>

Commit 870c774b866c ("igt/gem_exec_nop: Add expectancy of independent
execution between engines") extended a "basic" subtest (now
"basic-series") with a pass/fail metric based on comparison of parallel
execution time to be less than an average * 2.  Since then, that limit
has been raised quite a few times:
- by commit 41a26b5152a5 ("igt/gem_exec_nop: Relax parallel assertion
  for short rings") to maximum + minimum,
- by commit 7bd4f918c461 ("igt/gem_exec_nop: Explain the parallel
  execution assertion") to maximum + minimum * 10/9,
- by commit a0eebbddecaa ("igt/gem_exec_nop: Relax assertion for
  parallel execution") to sum * 2.

With the criteria relaxed up to that extent, the purpose of that check
has been limited to a showcase for an old GuC failure.  Since that is
now obsolete, kill that assert.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
 tests/i915/gem_exec_nop.c | 17 -----------------
 1 file changed, 17 deletions(-)

diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
index 357449c5b..c17d672c3 100644
--- a/tests/i915/gem_exec_nop.c
+++ b/tests/i915/gem_exec_nop.c
@@ -682,23 +682,6 @@ static void series(int fd, uint32_t handle, int timeout)
 	time = elapsed(&start, &now) / count;
 	igt_info("All (%d engines): %'lu cycles, average %.3fus per cycle [expected %.3fus]\n",
 		 nengine, count, 1e6*time, 1e6*((max-min)/nengine+min));
-
-	/* The rate limiting step should be how fast the slowest engine can
-	 * execute its queue of requests, as when we wait upon a full ring all
-	 * dispatch is frozen. So in general we cannot go faster than the
-	 * slowest engine (but as all engines are in lockstep, they should all
-	 * be executing in parallel and so the average should be max/nengines),
-	 * but we should equally not go any slower.
-	 *
-	 * However, that depends upon being able to submit fast enough, and
-	 * that in turns depends upon debugging turned off and no bottlenecks
-	 * within the driver. We cannot assert that we hit ideal conditions
-	 * across all engines, so we only look for an outrageous error
-	 * condition.
-	 */
-	igt_assert_f(time < 2*sum,
-		     "Average time (%.3fus) exceeds expectation for parallel execution (min %.3fus, max %.3fus; limit set at %.3fus)\n",
-		     1e6*time, 1e6*min, 1e6*max, 1e6*sum*2);
 }
 
 static void xchg(void *array, unsigned i, unsigned j)
-- 
2.21.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2020-05-08 13:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 13:56 [igt-dev] [PATCH i-g-t 0/2] tests/gem_exec_nop: Remove submission batching Janusz Krzysztofik
2020-05-08 13:56 ` Janusz Krzysztofik [this message]
2020-05-08 17:46   ` [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric Chris Wilson
2020-05-08 13:56 ` [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching Janusz Krzysztofik
2020-05-08 17:54   ` Chris Wilson
2020-05-11  8:51     ` Janusz Krzysztofik
2020-05-11  9:30       ` [igt-dev] [Intel-gfx] " Chris Wilson
2020-05-08 14:35 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2020-05-08 17:12 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=20200508135631.8099-2-janusz.krzysztofik@linux.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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