All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH i-g-t 0/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-08 13:56 ` Janusz Krzysztofik
  0 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

Execbuf requests are now submitted by subtests in batches of 1024
repetitions.  That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.

Kill obsolete showcase for an old GuC failure, then remove submission
batching from subtests which don't require submicrosecond precision.

Janusz Krzysztofik (2):
  tests/gem_exec_nop: Kill obsolete pass/fail metric
  tests/gem_exec_nop: Remove submission batching

 tests/i915/gem_exec_nop.c | 137 ++++++++++++++++----------------------
 1 file changed, 59 insertions(+), 78 deletions(-)

-- 
2.21.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [igt-dev] [PATCH i-g-t 0/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-08 13:56 ` Janusz Krzysztofik
  0 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

Execbuf requests are now submitted by subtests in batches of 1024
repetitions.  That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.

Kill obsolete showcase for an old GuC failure, then remove submission
batching from subtests which don't require submicrosecond precision.

Janusz Krzysztofik (2):
  tests/gem_exec_nop: Kill obsolete pass/fail metric
  tests/gem_exec_nop: Remove submission batching

 tests/i915/gem_exec_nop.c | 137 ++++++++++++++++----------------------
 1 file changed, 59 insertions(+), 78 deletions(-)

-- 
2.21.1

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-gfx] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric
  2020-05-08 13:56 ` [igt-dev] " Janusz Krzysztofik
@ 2020-05-08 13:56   ` Janusz Krzysztofik
  -1 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric
@ 2020-05-08 13:56   ` Janusz Krzysztofik
  0 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
  2020-05-08 13:56 ` [igt-dev] " Janusz Krzysztofik
@ 2020-05-08 13:56   ` Janusz Krzysztofik
  -1 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

Execbuf requests are now submitted by subtests in batches of 1024
repetitions.  That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.

The reason standing behind that batching was unacceptable microsecond
imprecision of gettime when gem_exec_nop was a benchmark rather than a
test and time measurement was looking for a precision of ~100 ns.
Since that measurement is now mostly informative and not a pass/fail
metric, we can be more tolerant and accept overhead of gettime after
each submission.

Remove the batching from the body of subtests which don't require
submicrosecond precision and measure time after each execbuf request
submission (or a group of one submission per engine).  Since there is
one subtest - "headless" - which still requires more precise time
measurement, don't remove the batching from nop_on_ring() helper but
let its users request non-batched submission mode instead.  To make
this even more flexible, change semantics of the helper argument used
so far for returning the count of submissions completed within the
requested time frame and use it also for passing desired batch size
(number of iterations), then update its users to initialize that
argument according to their individual requirements.

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 | 120 +++++++++++++++++++-------------------
 1 file changed, 59 insertions(+), 61 deletions(-)

diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
index c17d672c3..10639765b 100644
--- a/tests/i915/gem_exec_nop.c
+++ b/tests/i915/gem_exec_nop.c
@@ -71,12 +71,14 @@ static double elapsed(const struct timespec *start, const struct timespec *end)
 
 static double nop_on_ring(int fd, uint32_t handle,
 			  const struct intel_execution_engine2 *e, int timeout,
-			  unsigned long *out)
+			  unsigned long *count)
 {
 	struct drm_i915_gem_execbuffer2 execbuf;
 	struct drm_i915_gem_exec_object2 obj;
 	struct timespec start, now;
-	unsigned long count;
+	unsigned long total;
+
+	igt_assert(*count);
 
 	memset(&obj, 0, sizeof(obj));
 	obj.handle = handle;
@@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
 	}
 	intel_detect_and_clear_missed_interrupts(fd);
 
-	count = 0;
+	total = 0;
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++)
+		for (int loop = 0; loop < *count; loop++)
 			gem_execbuf(fd, &execbuf);
 
-		count += 1024;
+		total += *count;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 
-	*out = count;
+	*count = total;
 	return elapsed(&start, &now);
 }
 
@@ -353,7 +355,7 @@ static void single(int fd, uint32_t handle,
 		   const struct intel_execution_engine2 *e)
 {
 	double time;
-	unsigned long count;
+	unsigned long count = 1;
 
 	time = nop_on_ring(fd, handle, e, 20, &count);
 	igt_info("%s: %'lu cycles: %.3fus\n",
@@ -374,7 +376,7 @@ stable_nop_on_ring(int fd, uint32_t handle,
 	s.is_float = true;
 
 	while (reps--) {
-		unsigned long count;
+		unsigned long count = 1024;
 		double time;
 
 		time = nop_on_ring(fd, handle, e, timeout, &count);
@@ -451,6 +453,7 @@ static void parallel(int fd, uint32_t handle, int timeout)
 		engines[nengine] = e->flags;
 		names[nengine++] = strdup(e->name);
 
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
 		igt_debug("%s: %.3fus\n", e->name, 1e6*time);
@@ -481,9 +484,8 @@ static void parallel(int fd, uint32_t handle, int timeout)
 		count = 0;
 		clock_gettime(CLOCK_MONOTONIC, &start);
 		do {
-			for (int loop = 0; loop < 1024; loop++)
-				gem_execbuf(fd, &execbuf);
-			count += 1024;
+			gem_execbuf(fd, &execbuf);
+			count++;
 			clock_gettime(CLOCK_MONOTONIC, &now);
 		} while (elapsed(&start, &now) < timeout);
 		time = elapsed(&start, &now) / count;
@@ -513,6 +515,7 @@ static void independent(int fd, uint32_t handle, int timeout)
 		engines[nengine] = e->flags;
 		names[nengine++] = strdup(e->name);
 
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
 		igt_debug("%s: %.3fus\n", e->name, 1e6*time);
@@ -633,6 +636,7 @@ static void series(int fd, uint32_t handle, int timeout)
 
 	nengine = 0;
 	__for_each_physical_engine(fd, e) {
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		if (time > max) {
 			name = e->name;
@@ -664,14 +668,12 @@ static void series(int fd, uint32_t handle, int timeout)
 	count = 0;
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++) {
-			for (int n = 0; n < nengine; n++) {
-				execbuf.flags &= ~ENGINE_FLAGS;
-				execbuf.flags |= engines[n];
-				gem_execbuf(fd, &execbuf);
-			}
+		for (int n = 0; n < nengine; n++) {
+			execbuf.flags &= ~ENGINE_FLAGS;
+			execbuf.flags |= engines[n];
+			gem_execbuf(fd, &execbuf);
 		}
-		count += nengine * 1024;
+		count += nengine;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout); /* Hang detection ~120s */
 	gem_sync(fd, handle);
@@ -712,7 +714,7 @@ static void sequential(int fd, uint32_t handle, unsigned flags, int timeout)
 	nengine = 0;
 	sum = 0;
 	__for_each_physical_engine(fd, e) {
-		unsigned long count;
+		unsigned long count = 1;
 
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
@@ -765,27 +767,31 @@ static void sequential(int fd, uint32_t handle, unsigned flags, int timeout)
 
 		count = 0;
 		clock_gettime(CLOCK_MONOTONIC, &start);
-		do {
+		if (flags & CHAINED) {
 			igt_permute_array(engines, nengine, xchg);
-			if (flags & CHAINED) {
+			for (n = 0; n < nengine; n++) {
+				execbuf.flags &= ~ENGINE_FLAGS;
+				execbuf.flags |= engines[n];
+				do {
+					gem_execbuf(fd, &execbuf);
+					count++;
+					clock_gettime(CLOCK_MONOTONIC,
+							      &now);
+				} while (elapsed(&start, &now) <
+						timeout * (n + 1) / nengine);
+			}
+		} else {
+			do {
+				igt_permute_array(engines, nengine, xchg);
 				for (n = 0; n < nengine; n++) {
 					execbuf.flags &= ~ENGINE_FLAGS;
 					execbuf.flags |= engines[n];
-					for (int loop = 0; loop < 1024; loop++)
-						gem_execbuf(fd, &execbuf);
+					gem_execbuf(fd, &execbuf);
 				}
-			} else {
-				for (int loop = 0; loop < 1024; loop++) {
-					for (n = 0; n < nengine; n++) {
-						execbuf.flags &= ~ENGINE_FLAGS;
-						execbuf.flags |= engines[n];
-						gem_execbuf(fd, &execbuf);
-					}
-				}
-			}
-			count += 1024;
-			clock_gettime(CLOCK_MONOTONIC, &now);
-		} while (elapsed(&start, &now) < timeout); /* Hang detection ~120s */
+				count++;
+				clock_gettime(CLOCK_MONOTONIC, &now);
+			} while (elapsed(&start, &now) < timeout);
+		}
 
 		gem_sync(fd, obj[0].handle);
 		clock_gettime(CLOCK_MONOTONIC, &now);
@@ -869,26 +875,24 @@ static void fence_signal(int fd, uint32_t handle,
 	intel_detect_and_clear_missed_interrupts(fd);
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++) {
-			for (int e = 0; e < nengine; e++) {
-				if (fences[n] != -1) {
-					igt_assert(fence_wait(fences[n]));
-					close(fences[n]);
-				}
+		for (int e = 0; e < nengine; e++) {
+			if (fences[n] != -1) {
+				igt_assert(fence_wait(fences[n]));
+				close(fences[n]);
+			}
 
-				execbuf.flags &= ~ENGINE_FLAGS;
-				execbuf.flags |= engines[e];
-				gem_execbuf_wr(fd, &execbuf);
+			execbuf.flags &= ~ENGINE_FLAGS;
+			execbuf.flags |= engines[e];
+			gem_execbuf_wr(fd, &execbuf);
 
-				/* Enable signaling by doing a poll() */
-				fences[n] = execbuf.rsvd2 >> 32;
-				signal += fence_enable_signaling(fences[n]);
+			/* Enable signaling by doing a poll() */
+			fences[n] = execbuf.rsvd2 >> 32;
+			signal += fence_enable_signaling(fences[n]);
 
-				n = (n + 1) % NFENCES;
-			}
+			n = (n + 1) % NFENCES;
 		}
 
-		count += 1024 * nengine;
+		count += nengine;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
@@ -910,6 +914,7 @@ static void preempt(int fd, uint32_t handle,
 	struct timespec start, now;
 	unsigned long count;
 	uint32_t ctx[2];
+	igt_spin_t *spin;
 
 	ctx[0] = gem_context_clone_with_engines(fd, 0);
 	gem_context_set_priority(fd, ctx[0], MIN_PRIO);
@@ -934,21 +939,14 @@ static void preempt(int fd, uint32_t handle,
 	intel_detect_and_clear_missed_interrupts(fd);
 
 	count = 0;
+	spin = __igt_spin_new(fd, .ctx = ctx[0], .engine = e->flags);
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		igt_spin_t *spin =
-			__igt_spin_new(fd,
-				       .ctx = ctx[0],
-				       .engine = e->flags);
-
-		for (int loop = 0; loop < 1024; loop++)
-			gem_execbuf(fd, &execbuf);
-
-		igt_spin_free(fd, spin);
-
-		count += 1024;
+		gem_execbuf(fd, &execbuf);
+		count++;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < 20);
+	igt_spin_free(fd, spin);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 
 	gem_context_destroy(fd, ctx[1]);
-- 
2.21.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-08 13:56   ` Janusz Krzysztofik
  0 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-08 13:56 UTC (permalink / raw)
  To: igt-dev; +Cc: intel-gfx, Chris Wilson

Execbuf requests are now submitted by subtests in batches of 1024
repetitions.  That may be too many under some circumstances (e.g.,
intensive logging output) and subtests may take far more time than
expected.

The reason standing behind that batching was unacceptable microsecond
imprecision of gettime when gem_exec_nop was a benchmark rather than a
test and time measurement was looking for a precision of ~100 ns.
Since that measurement is now mostly informative and not a pass/fail
metric, we can be more tolerant and accept overhead of gettime after
each submission.

Remove the batching from the body of subtests which don't require
submicrosecond precision and measure time after each execbuf request
submission (or a group of one submission per engine).  Since there is
one subtest - "headless" - which still requires more precise time
measurement, don't remove the batching from nop_on_ring() helper but
let its users request non-batched submission mode instead.  To make
this even more flexible, change semantics of the helper argument used
so far for returning the count of submissions completed within the
requested time frame and use it also for passing desired batch size
(number of iterations), then update its users to initialize that
argument according to their individual requirements.

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 | 120 +++++++++++++++++++-------------------
 1 file changed, 59 insertions(+), 61 deletions(-)

diff --git a/tests/i915/gem_exec_nop.c b/tests/i915/gem_exec_nop.c
index c17d672c3..10639765b 100644
--- a/tests/i915/gem_exec_nop.c
+++ b/tests/i915/gem_exec_nop.c
@@ -71,12 +71,14 @@ static double elapsed(const struct timespec *start, const struct timespec *end)
 
 static double nop_on_ring(int fd, uint32_t handle,
 			  const struct intel_execution_engine2 *e, int timeout,
-			  unsigned long *out)
+			  unsigned long *count)
 {
 	struct drm_i915_gem_execbuffer2 execbuf;
 	struct drm_i915_gem_exec_object2 obj;
 	struct timespec start, now;
-	unsigned long count;
+	unsigned long total;
+
+	igt_assert(*count);
 
 	memset(&obj, 0, sizeof(obj));
 	obj.handle = handle;
@@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
 	}
 	intel_detect_and_clear_missed_interrupts(fd);
 
-	count = 0;
+	total = 0;
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++)
+		for (int loop = 0; loop < *count; loop++)
 			gem_execbuf(fd, &execbuf);
 
-		count += 1024;
+		total += *count;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 
-	*out = count;
+	*count = total;
 	return elapsed(&start, &now);
 }
 
@@ -353,7 +355,7 @@ static void single(int fd, uint32_t handle,
 		   const struct intel_execution_engine2 *e)
 {
 	double time;
-	unsigned long count;
+	unsigned long count = 1;
 
 	time = nop_on_ring(fd, handle, e, 20, &count);
 	igt_info("%s: %'lu cycles: %.3fus\n",
@@ -374,7 +376,7 @@ stable_nop_on_ring(int fd, uint32_t handle,
 	s.is_float = true;
 
 	while (reps--) {
-		unsigned long count;
+		unsigned long count = 1024;
 		double time;
 
 		time = nop_on_ring(fd, handle, e, timeout, &count);
@@ -451,6 +453,7 @@ static void parallel(int fd, uint32_t handle, int timeout)
 		engines[nengine] = e->flags;
 		names[nengine++] = strdup(e->name);
 
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
 		igt_debug("%s: %.3fus\n", e->name, 1e6*time);
@@ -481,9 +484,8 @@ static void parallel(int fd, uint32_t handle, int timeout)
 		count = 0;
 		clock_gettime(CLOCK_MONOTONIC, &start);
 		do {
-			for (int loop = 0; loop < 1024; loop++)
-				gem_execbuf(fd, &execbuf);
-			count += 1024;
+			gem_execbuf(fd, &execbuf);
+			count++;
 			clock_gettime(CLOCK_MONOTONIC, &now);
 		} while (elapsed(&start, &now) < timeout);
 		time = elapsed(&start, &now) / count;
@@ -513,6 +515,7 @@ static void independent(int fd, uint32_t handle, int timeout)
 		engines[nengine] = e->flags;
 		names[nengine++] = strdup(e->name);
 
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
 		igt_debug("%s: %.3fus\n", e->name, 1e6*time);
@@ -633,6 +636,7 @@ static void series(int fd, uint32_t handle, int timeout)
 
 	nengine = 0;
 	__for_each_physical_engine(fd, e) {
+		count = 1;
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		if (time > max) {
 			name = e->name;
@@ -664,14 +668,12 @@ static void series(int fd, uint32_t handle, int timeout)
 	count = 0;
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++) {
-			for (int n = 0; n < nengine; n++) {
-				execbuf.flags &= ~ENGINE_FLAGS;
-				execbuf.flags |= engines[n];
-				gem_execbuf(fd, &execbuf);
-			}
+		for (int n = 0; n < nengine; n++) {
+			execbuf.flags &= ~ENGINE_FLAGS;
+			execbuf.flags |= engines[n];
+			gem_execbuf(fd, &execbuf);
 		}
-		count += nengine * 1024;
+		count += nengine;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout); /* Hang detection ~120s */
 	gem_sync(fd, handle);
@@ -712,7 +714,7 @@ static void sequential(int fd, uint32_t handle, unsigned flags, int timeout)
 	nengine = 0;
 	sum = 0;
 	__for_each_physical_engine(fd, e) {
-		unsigned long count;
+		unsigned long count = 1;
 
 		time = nop_on_ring(fd, handle, e, 1, &count) / count;
 		sum += time;
@@ -765,27 +767,31 @@ static void sequential(int fd, uint32_t handle, unsigned flags, int timeout)
 
 		count = 0;
 		clock_gettime(CLOCK_MONOTONIC, &start);
-		do {
+		if (flags & CHAINED) {
 			igt_permute_array(engines, nengine, xchg);
-			if (flags & CHAINED) {
+			for (n = 0; n < nengine; n++) {
+				execbuf.flags &= ~ENGINE_FLAGS;
+				execbuf.flags |= engines[n];
+				do {
+					gem_execbuf(fd, &execbuf);
+					count++;
+					clock_gettime(CLOCK_MONOTONIC,
+							      &now);
+				} while (elapsed(&start, &now) <
+						timeout * (n + 1) / nengine);
+			}
+		} else {
+			do {
+				igt_permute_array(engines, nengine, xchg);
 				for (n = 0; n < nengine; n++) {
 					execbuf.flags &= ~ENGINE_FLAGS;
 					execbuf.flags |= engines[n];
-					for (int loop = 0; loop < 1024; loop++)
-						gem_execbuf(fd, &execbuf);
+					gem_execbuf(fd, &execbuf);
 				}
-			} else {
-				for (int loop = 0; loop < 1024; loop++) {
-					for (n = 0; n < nengine; n++) {
-						execbuf.flags &= ~ENGINE_FLAGS;
-						execbuf.flags |= engines[n];
-						gem_execbuf(fd, &execbuf);
-					}
-				}
-			}
-			count += 1024;
-			clock_gettime(CLOCK_MONOTONIC, &now);
-		} while (elapsed(&start, &now) < timeout); /* Hang detection ~120s */
+				count++;
+				clock_gettime(CLOCK_MONOTONIC, &now);
+			} while (elapsed(&start, &now) < timeout);
+		}
 
 		gem_sync(fd, obj[0].handle);
 		clock_gettime(CLOCK_MONOTONIC, &now);
@@ -869,26 +875,24 @@ static void fence_signal(int fd, uint32_t handle,
 	intel_detect_and_clear_missed_interrupts(fd);
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		for (int loop = 0; loop < 1024; loop++) {
-			for (int e = 0; e < nengine; e++) {
-				if (fences[n] != -1) {
-					igt_assert(fence_wait(fences[n]));
-					close(fences[n]);
-				}
+		for (int e = 0; e < nengine; e++) {
+			if (fences[n] != -1) {
+				igt_assert(fence_wait(fences[n]));
+				close(fences[n]);
+			}
 
-				execbuf.flags &= ~ENGINE_FLAGS;
-				execbuf.flags |= engines[e];
-				gem_execbuf_wr(fd, &execbuf);
+			execbuf.flags &= ~ENGINE_FLAGS;
+			execbuf.flags |= engines[e];
+			gem_execbuf_wr(fd, &execbuf);
 
-				/* Enable signaling by doing a poll() */
-				fences[n] = execbuf.rsvd2 >> 32;
-				signal += fence_enable_signaling(fences[n]);
+			/* Enable signaling by doing a poll() */
+			fences[n] = execbuf.rsvd2 >> 32;
+			signal += fence_enable_signaling(fences[n]);
 
-				n = (n + 1) % NFENCES;
-			}
+			n = (n + 1) % NFENCES;
 		}
 
-		count += 1024 * nengine;
+		count += nengine;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < timeout);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
@@ -910,6 +914,7 @@ static void preempt(int fd, uint32_t handle,
 	struct timespec start, now;
 	unsigned long count;
 	uint32_t ctx[2];
+	igt_spin_t *spin;
 
 	ctx[0] = gem_context_clone_with_engines(fd, 0);
 	gem_context_set_priority(fd, ctx[0], MIN_PRIO);
@@ -934,21 +939,14 @@ static void preempt(int fd, uint32_t handle,
 	intel_detect_and_clear_missed_interrupts(fd);
 
 	count = 0;
+	spin = __igt_spin_new(fd, .ctx = ctx[0], .engine = e->flags);
 	clock_gettime(CLOCK_MONOTONIC, &start);
 	do {
-		igt_spin_t *spin =
-			__igt_spin_new(fd,
-				       .ctx = ctx[0],
-				       .engine = e->flags);
-
-		for (int loop = 0; loop < 1024; loop++)
-			gem_execbuf(fd, &execbuf);
-
-		igt_spin_free(fd, spin);
-
-		count += 1024;
+		gem_execbuf(fd, &execbuf);
+		count++;
 		clock_gettime(CLOCK_MONOTONIC, &now);
 	} while (elapsed(&start, &now) < 20);
+	igt_spin_free(fd, spin);
 	igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
 
 	gem_context_destroy(fd, ctx[1]);
-- 
2.21.1

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

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [igt-dev] ✓ Fi.CI.BAT: success for tests/gem_exec_nop: Remove submission batching
  2020-05-08 13:56 ` [igt-dev] " Janusz Krzysztofik
                   ` (2 preceding siblings ...)
  (?)
@ 2020-05-08 14:35 ` Patchwork
  -1 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2020-05-08 14:35 UTC (permalink / raw)
  To: Janusz Krzysztofik; +Cc: igt-dev

== Series Details ==

Series: tests/gem_exec_nop: Remove submission batching
URL   : https://patchwork.freedesktop.org/series/77077/
State : success

== Summary ==

CI Bug Log - changes from IGT_5642 -> IGTPW_4548
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html


Changes
-------

  No changes found


Participating hosts (48 -> 41)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5642 -> IGTPW_4548

  CI-20190529: 20190529
  CI_DRM_8452: 8dbf7b1ac5c55b27306ba1a8cc3dc0e1ef9938e8 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4548: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html
  IGT_5642: d1ce4abb01c70f7be6e777b6d45442663c4b830e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [igt-dev] ✗ Fi.CI.IGT: failure for tests/gem_exec_nop: Remove submission batching
  2020-05-08 13:56 ` [igt-dev] " Janusz Krzysztofik
                   ` (3 preceding siblings ...)
  (?)
@ 2020-05-08 17:12 ` Patchwork
  -1 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2020-05-08 17:12 UTC (permalink / raw)
  To: Janusz Krzysztofik; +Cc: igt-dev

== Series Details ==

Series: tests/gem_exec_nop: Remove submission batching
URL   : https://patchwork.freedesktop.org/series/77077/
State : failure

== Summary ==

CI Bug Log - changes from IGT_5642_full -> IGTPW_4548_full
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_4548_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_4548_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_4548_full:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@gt_pm:
    - shard-apl:          [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl6/igt@i915_selftest@live@gt_pm.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl7/igt@i915_selftest@live@gt_pm.html

  
Known issues
------------

  Here are the changes found in IGTPW_4548_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_params@invalid-bsd-ring:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-iclb4/igt@gem_exec_params@invalid-bsd-ring.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-iclb7/igt@gem_exec_params@invalid-bsd-ring.html

  * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
    - shard-kbl:          [PASS][5] -> [FAIL][6] ([i915#54] / [i915#93] / [i915#95])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl3/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-apl:          [PASS][7] -> [FAIL][8] ([i915#54] / [i915#62])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-untiled:
    - shard-apl:          [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54] / [i915#95])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl7/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-untiled.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl1/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-untiled.html

  * igt@kms_flip_tiling@flip-changes-tiling-y:
    - shard-kbl:          [PASS][11] -> [FAIL][12] ([i915#699] / [i915#93] / [i915#95])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl2/igt@kms_flip_tiling@flip-changes-tiling-y.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl3/igt@kms_flip_tiling@flip-changes-tiling-y.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
    - shard-tglb:         [PASS][13] -> [INCOMPLETE][14] ([i915#1602])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-tglb5/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-tglb1/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
    - shard-apl:          [PASS][15] -> [DMESG-WARN][16] ([i915#180])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl8/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl8/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-mid:
    - shard-kbl:          [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265] / [i915#93] / [i915#95])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-mid.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl7/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-mid.html
    - shard-apl:          [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265] / [i915#95])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-mid.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-mid.html

  * igt@kms_plane_cursor@pipe-a-viewport-size-256:
    - shard-apl:          [PASS][21] -> [FAIL][22] ([i915#1559] / [i915#95])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl3/igt@kms_plane_cursor@pipe-a-viewport-size-256.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl6/igt@kms_plane_cursor@pipe-a-viewport-size-256.html
    - shard-kbl:          [PASS][23] -> [FAIL][24] ([i915#1559] / [i915#93] / [i915#95])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl3/igt@kms_plane_cursor@pipe-a-viewport-size-256.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl6/igt@kms_plane_cursor@pipe-a-viewport-size-256.html

  * igt@kms_psr@no_drrs:
    - shard-iclb:         [PASS][25] -> [FAIL][26] ([i915#173])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-iclb4/igt@kms_psr@no_drrs.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-iclb1/igt@kms_psr@no_drrs.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [PASS][27] -> [SKIP][28] ([fdo#109441]) +2 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@perf@stress-open-close:
    - shard-tglb:         [PASS][29] -> [INCOMPLETE][30] ([i915#1356])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-tglb7/igt@perf@stress-open-close.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-tglb5/igt@perf@stress-open-close.html

  
#### Possible fixes ####

  * igt@kms_cursor_crc@pipe-a-cursor-256x256-offscreen:
    - shard-kbl:          [FAIL][31] ([i915#54] / [i915#93] / [i915#95]) -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-256x256-offscreen.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-256x256-offscreen.html

  * igt@kms_draw_crc@draw-method-xrgb8888-blt-untiled:
    - shard-apl:          [FAIL][33] ([i915#52] / [i915#54] / [i915#95]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl3/igt@kms_draw_crc@draw-method-xrgb8888-blt-untiled.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl7/igt@kms_draw_crc@draw-method-xrgb8888-blt-untiled.html
    - shard-kbl:          [FAIL][35] ([i915#177] / [i915#52] / [i915#54] / [i915#93] / [i915#95]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl3/igt@kms_draw_crc@draw-method-xrgb8888-blt-untiled.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl1/igt@kms_draw_crc@draw-method-xrgb8888-blt-untiled.html

  * {igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1}:
    - shard-hsw:          [INCOMPLETE][37] ([i915#61]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-hsw6/igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1.html

  * {igt@kms_flip@flip-vs-suspend@b-dp1}:
    - shard-apl:          [DMESG-WARN][39] ([i915#180]) -> [PASS][40] +2 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl2/igt@kms_flip@flip-vs-suspend@b-dp1.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl3/igt@kms_flip@flip-vs-suspend@b-dp1.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-apl:          [FAIL][41] ([i915#1188]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_hdr@bpc-switch-suspend.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl8/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
    - shard-apl:          [FAIL][43] ([fdo#108145] / [i915#265] / [i915#95]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl4/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html

  * igt@kms_plane_cursor@pipe-a-overlay-size-128:
    - shard-kbl:          [FAIL][45] ([i915#1559] / [i915#93] / [i915#95]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl4/igt@kms_plane_cursor@pipe-a-overlay-size-128.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl1/igt@kms_plane_cursor@pipe-a-overlay-size-128.html
    - shard-apl:          [FAIL][47] ([i915#1559] / [i915#95]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_plane_cursor@pipe-a-overlay-size-128.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl4/igt@kms_plane_cursor@pipe-a-overlay-size-128.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [SKIP][49] ([fdo#109441]) -> [PASS][50] +1 similar issue
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-iclb3/igt@kms_psr@psr2_cursor_render.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-iclb2/igt@kms_psr@psr2_cursor_render.html

  * {igt@perf@blocking-parameterized}:
    - shard-iclb:         [FAIL][51] ([i915#1542]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-iclb3/igt@perf@blocking-parameterized.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-iclb3/igt@perf@blocking-parameterized.html

  * igt@perf@enable-disable:
    - shard-glk:          [INCOMPLETE][53] ([i915#58] / [k.org#198133]) -> [PASS][54]
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-glk8/igt@perf@enable-disable.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-glk9/igt@perf@enable-disable.html

  
#### Warnings ####

  * igt@kms_content_protection@atomic:
    - shard-apl:          [FAIL][55] ([fdo#110321] / [fdo#110336]) -> [TIMEOUT][56] ([i915#1319])
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_content_protection@atomic.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl3/igt@kms_content_protection@atomic.html

  * igt@kms_content_protection@lic:
    - shard-apl:          [FAIL][57] ([fdo#110321]) -> [FAIL][58] ([fdo#110321] / [i915#95])
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl4/igt@kms_content_protection@lic.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl7/igt@kms_content_protection@lic.html

  * igt@kms_fbcon_fbt@fbc-suspend:
    - shard-apl:          [FAIL][59] ([i915#1525]) -> [FAIL][60] ([i915#95])
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl7/igt@kms_fbcon_fbt@fbc-suspend.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl3/igt@kms_fbcon_fbt@fbc-suspend.html
    - shard-kbl:          [FAIL][61] ([i915#64]) -> [FAIL][62] ([i915#93] / [i915#95])
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-kbl6/igt@kms_fbcon_fbt@fbc-suspend.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
    - shard-apl:          [FAIL][63] ([fdo#108145] / [i915#265]) -> [FAIL][64] ([fdo#108145] / [i915#265] / [i915#62])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5642/shard-apl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/shard-apl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110321]: https://bugs.freedesktop.org/show_bug.cgi?id=110321
  [fdo#110336]: https://bugs.freedesktop.org/show_bug.cgi?id=110336
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#1356]: https://gitlab.freedesktop.org/drm/intel/issues/1356
  [i915#1525]: https://gitlab.freedesktop.org/drm/intel/issues/1525
  [i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
  [i915#1559]: https://gitlab.freedesktop.org/drm/intel/issues/1559
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
  [i915#177]: https://gitlab.freedesktop.org/drm/intel/issues/177
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
  [i915#407]: https://gitlab.freedesktop.org/drm/intel/issues/407
  [i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#64]: https://gitlab.freedesktop.org/drm/intel/issues/64
  [i915#699]: https://gitlab.freedesktop.org/drm/intel/issues/699
  [i915#93]: https://gitlab.freedesktop.org/drm/intel/issues/93
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (8 -> 8)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5642 -> IGTPW_4548

  CI-20190529: 20190529
  CI_DRM_8452: 8dbf7b1ac5c55b27306ba1a8cc3dc0e1ef9938e8 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4548: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html
  IGT_5642: d1ce4abb01c70f7be6e777b6d45442663c4b830e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4548/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric
  2020-05-08 13:56   ` [igt-dev] " Janusz Krzysztofik
@ 2020-05-08 17:46     ` Chris Wilson
  -1 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-08 17:46 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-08 14:56:30)
> 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>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [igt-dev] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric
@ 2020-05-08 17:46     ` Chris Wilson
  0 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-08 17:46 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-08 14:56:30)
> 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>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
  2020-05-08 13:56   ` [igt-dev] " Janusz Krzysztofik
@ 2020-05-08 17:54     ` Chris Wilson
  -1 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-08 17:54 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
>  static double nop_on_ring(int fd, uint32_t handle,
>                           const struct intel_execution_engine2 *e, int timeout,
> -                         unsigned long *out)
> +                         unsigned long *count)
>  {
>         struct drm_i915_gem_execbuffer2 execbuf;
>         struct drm_i915_gem_exec_object2 obj;
>         struct timespec start, now;
> -       unsigned long count;
> +       unsigned long total;
> +
> +       igt_assert(*count);
>  
>         memset(&obj, 0, sizeof(obj));
>         obj.handle = handle;
> @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
>         }
>         intel_detect_and_clear_missed_interrupts(fd);
>  
> -       count = 0;
> +       total = 0;
>         clock_gettime(CLOCK_MONOTONIC, &start);
>         do {
> -               for (int loop = 0; loop < 1024; loop++)
> +               for (int loop = 0; loop < *count; loop++)

This unnerves me. I expect to get this wrong when writing new callers.

There's no great reason to even have 1024 here, we can survive with
doing clock_gettime() every iteration, and just accept it as part of the
systematic cost.

>                         gem_execbuf(fd, &execbuf);
>  
> -               count += 1024;
> +               total += *count;
>                 clock_gettime(CLOCK_MONOTONIC, &now);
>         } while (elapsed(&start, &now) < timeout);
>         igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
>  
> -       *out = count;
> +       *count = total;
>         return elapsed(&start, &now);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-08 17:54     ` Chris Wilson
  0 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-08 17:54 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
>  static double nop_on_ring(int fd, uint32_t handle,
>                           const struct intel_execution_engine2 *e, int timeout,
> -                         unsigned long *out)
> +                         unsigned long *count)
>  {
>         struct drm_i915_gem_execbuffer2 execbuf;
>         struct drm_i915_gem_exec_object2 obj;
>         struct timespec start, now;
> -       unsigned long count;
> +       unsigned long total;
> +
> +       igt_assert(*count);
>  
>         memset(&obj, 0, sizeof(obj));
>         obj.handle = handle;
> @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
>         }
>         intel_detect_and_clear_missed_interrupts(fd);
>  
> -       count = 0;
> +       total = 0;
>         clock_gettime(CLOCK_MONOTONIC, &start);
>         do {
> -               for (int loop = 0; loop < 1024; loop++)
> +               for (int loop = 0; loop < *count; loop++)

This unnerves me. I expect to get this wrong when writing new callers.

There's no great reason to even have 1024 here, we can survive with
doing clock_gettime() every iteration, and just accept it as part of the
systematic cost.

>                         gem_execbuf(fd, &execbuf);
>  
> -               count += 1024;
> +               total += *count;
>                 clock_gettime(CLOCK_MONOTONIC, &now);
>         } while (elapsed(&start, &now) < timeout);
>         igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
>  
> -       *out = count;
> +       *count = total;
>         return elapsed(&start, &now);
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
  2020-05-08 17:54     ` Chris Wilson
@ 2020-05-11  8:51       ` Janusz Krzysztofik
  -1 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-11  8:51 UTC (permalink / raw)
  To: Chris Wilson, igt-dev; +Cc: intel-gfx

Hi Chris,

On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> >  static double nop_on_ring(int fd, uint32_t handle,
> >                           const struct intel_execution_engine2 *e, int timeout,
> > -                         unsigned long *out)
> > +                         unsigned long *count)
> >  {
> >         struct drm_i915_gem_execbuffer2 execbuf;
> >         struct drm_i915_gem_exec_object2 obj;
> >         struct timespec start, now;
> > -       unsigned long count;
> > +       unsigned long total;
> > +
> > +       igt_assert(*count);
> >  
> >         memset(&obj, 0, sizeof(obj));
> >         obj.handle = handle;
> > @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
> >         }
> >         intel_detect_and_clear_missed_interrupts(fd);
> >  
> > -       count = 0;
> > +       total = 0;
> >         clock_gettime(CLOCK_MONOTONIC, &start);
> >         do {
> > -               for (int loop = 0; loop < 1024; loop++)
> > +               for (int loop = 0; loop < *count; loop++)
> 
> This unnerves me. I expect to get this wrong when writing new callers.
> 
> There's no great reason to even have 1024 here, we can survive with
> doing clock_gettime() every iteration, and just accept it as part of the
> systematic cost.

Thanks for fixing this and merging the change.

Following our discussion on IRC which I probably didn't understand
precisely enough but maybe have a better understanding now after having
it reread, how about still addressing the "headless" requirement for
better precision with the following hunk?

@@ -373,10 +372,12 @@ stable_nop_on_ring(int fd, uint32_t handle,
 	while (reps--) {
 		unsigned long count;
 		double time;
 
 		time = nop_on_ring(fd, handle, e, timeout, &count);
+		igt_skip_on_f(count < 1000 * timeout,
+			      "submicrosecond precision of time measurement\n");
 		igt_stats_push_float(&s, time / count);
 	}
 
 	n = igt_stats_get_median(&s);
 	igt_stats_fini(&s);

Thanks,
Janusz


> >  
> > -               count += 1024;
> > +               total += *count;
> >                 clock_gettime(CLOCK_MONOTONIC, &now);
> >         } while (elapsed(&start, &now) < timeout);
> >         igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
> >  
> > -       *out = count;
> > +       *count = total;
> >         return elapsed(&start, &now);

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-11  8:51       ` Janusz Krzysztofik
  0 siblings, 0 replies; 16+ messages in thread
From: Janusz Krzysztofik @ 2020-05-11  8:51 UTC (permalink / raw)
  To: Chris Wilson, igt-dev; +Cc: intel-gfx

Hi Chris,

On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> >  static double nop_on_ring(int fd, uint32_t handle,
> >                           const struct intel_execution_engine2 *e, int timeout,
> > -                         unsigned long *out)
> > +                         unsigned long *count)
> >  {
> >         struct drm_i915_gem_execbuffer2 execbuf;
> >         struct drm_i915_gem_exec_object2 obj;
> >         struct timespec start, now;
> > -       unsigned long count;
> > +       unsigned long total;
> > +
> > +       igt_assert(*count);
> >  
> >         memset(&obj, 0, sizeof(obj));
> >         obj.handle = handle;
> > @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
> >         }
> >         intel_detect_and_clear_missed_interrupts(fd);
> >  
> > -       count = 0;
> > +       total = 0;
> >         clock_gettime(CLOCK_MONOTONIC, &start);
> >         do {
> > -               for (int loop = 0; loop < 1024; loop++)
> > +               for (int loop = 0; loop < *count; loop++)
> 
> This unnerves me. I expect to get this wrong when writing new callers.
> 
> There's no great reason to even have 1024 here, we can survive with
> doing clock_gettime() every iteration, and just accept it as part of the
> systematic cost.

Thanks for fixing this and merging the change.

Following our discussion on IRC which I probably didn't understand
precisely enough but maybe have a better understanding now after having
it reread, how about still addressing the "headless" requirement for
better precision with the following hunk?

@@ -373,10 +372,12 @@ stable_nop_on_ring(int fd, uint32_t handle,
 	while (reps--) {
 		unsigned long count;
 		double time;
 
 		time = nop_on_ring(fd, handle, e, timeout, &count);
+		igt_skip_on_f(count < 1000 * timeout,
+			      "submicrosecond precision of time measurement\n");
 		igt_stats_push_float(&s, time / count);
 	}
 
 	n = igt_stats_get_median(&s);
 	igt_stats_fini(&s);

Thanks,
Janusz


> >  
> > -               count += 1024;
> > +               total += *count;
> >                 clock_gettime(CLOCK_MONOTONIC, &now);
> >         } while (elapsed(&start, &now) < timeout);
> >         igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
> >  
> > -       *out = count;
> > +       *count = total;
> >         return elapsed(&start, &now);

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
  2020-05-11  8:51       ` Janusz Krzysztofik
@ 2020-05-11  9:30         ` Chris Wilson
  -1 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-11  9:30 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-11 09:51:12)
> Hi Chris,
> 
> On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> > >  static double nop_on_ring(int fd, uint32_t handle,
> > >                           const struct intel_execution_engine2 *e, int timeout,
> > > -                         unsigned long *out)
> > > +                         unsigned long *count)
> > >  {
> > >         struct drm_i915_gem_execbuffer2 execbuf;
> > >         struct drm_i915_gem_exec_object2 obj;
> > >         struct timespec start, now;
> > > -       unsigned long count;
> > > +       unsigned long total;
> > > +
> > > +       igt_assert(*count);
> > >  
> > >         memset(&obj, 0, sizeof(obj));
> > >         obj.handle = handle;
> > > @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
> > >         }
> > >         intel_detect_and_clear_missed_interrupts(fd);
> > >  
> > > -       count = 0;
> > > +       total = 0;
> > >         clock_gettime(CLOCK_MONOTONIC, &start);
> > >         do {
> > > -               for (int loop = 0; loop < 1024; loop++)
> > > +               for (int loop = 0; loop < *count; loop++)
> > 
> > This unnerves me. I expect to get this wrong when writing new callers.
> > 
> > There's no great reason to even have 1024 here, we can survive with
> > doing clock_gettime() every iteration, and just accept it as part of the
> > systematic cost.
> 
> Thanks for fixing this and merging the change.
> 
> Following our discussion on IRC which I probably didn't understand
> precisely enough but maybe have a better understanding now after having
> it reread, how about still addressing the "headless" requirement for
> better precision with the following hunk?
> 
> @@ -373,10 +372,12 @@ stable_nop_on_ring(int fd, uint32_t handle,
>         while (reps--) {
>                 unsigned long count;
>                 double time;
>  
>                 time = nop_on_ring(fd, handle, e, timeout, &count);
> +               igt_skip_on_f(count < 1000 * timeout,
> +                             "submicrosecond precision of time measurement\n");

Yes. I just can't remember off the top of my head what order of
magnitude the error was -- I think it was around an extra 100us (50x
worse latency).
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [igt-dev] [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching
@ 2020-05-11  9:30         ` Chris Wilson
  0 siblings, 0 replies; 16+ messages in thread
From: Chris Wilson @ 2020-05-11  9:30 UTC (permalink / raw)
  To: Janusz Krzysztofik, igt-dev; +Cc: intel-gfx

Quoting Janusz Krzysztofik (2020-05-11 09:51:12)
> Hi Chris,
> 
> On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> > >  static double nop_on_ring(int fd, uint32_t handle,
> > >                           const struct intel_execution_engine2 *e, int timeout,
> > > -                         unsigned long *out)
> > > +                         unsigned long *count)
> > >  {
> > >         struct drm_i915_gem_execbuffer2 execbuf;
> > >         struct drm_i915_gem_exec_object2 obj;
> > >         struct timespec start, now;
> > > -       unsigned long count;
> > > +       unsigned long total;
> > > +
> > > +       igt_assert(*count);
> > >  
> > >         memset(&obj, 0, sizeof(obj));
> > >         obj.handle = handle;
> > > @@ -93,18 +95,18 @@ static double nop_on_ring(int fd, uint32_t handle,
> > >         }
> > >         intel_detect_and_clear_missed_interrupts(fd);
> > >  
> > > -       count = 0;
> > > +       total = 0;
> > >         clock_gettime(CLOCK_MONOTONIC, &start);
> > >         do {
> > > -               for (int loop = 0; loop < 1024; loop++)
> > > +               for (int loop = 0; loop < *count; loop++)
> > 
> > This unnerves me. I expect to get this wrong when writing new callers.
> > 
> > There's no great reason to even have 1024 here, we can survive with
> > doing clock_gettime() every iteration, and just accept it as part of the
> > systematic cost.
> 
> Thanks for fixing this and merging the change.
> 
> Following our discussion on IRC which I probably didn't understand
> precisely enough but maybe have a better understanding now after having
> it reread, how about still addressing the "headless" requirement for
> better precision with the following hunk?
> 
> @@ -373,10 +372,12 @@ stable_nop_on_ring(int fd, uint32_t handle,
>         while (reps--) {
>                 unsigned long count;
>                 double time;
>  
>                 time = nop_on_ring(fd, handle, e, timeout, &count);
> +               igt_skip_on_f(count < 1000 * timeout,
> +                             "submicrosecond precision of time measurement\n");

Yes. I just can't remember off the top of my head what order of
magnitude the error was -- I think it was around an extra 100us (50x
worse latency).
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-05-11  9:30 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-08 13:56 [Intel-gfx] [PATCH i-g-t 0/2] tests/gem_exec_nop: Remove submission batching Janusz Krzysztofik
2020-05-08 13:56 ` [igt-dev] " Janusz Krzysztofik
2020-05-08 13:56 ` [Intel-gfx] [PATCH i-g-t 1/2] tests/gem_exec_nop: Kill obsolete pass/fail metric Janusz Krzysztofik
2020-05-08 13:56   ` [igt-dev] " Janusz Krzysztofik
2020-05-08 17:46   ` [Intel-gfx] " Chris Wilson
2020-05-08 17:46     ` Chris Wilson
2020-05-08 13:56 ` [Intel-gfx] [PATCH i-g-t 2/2] tests/gem_exec_nop: Remove submission batching Janusz Krzysztofik
2020-05-08 13:56   ` [igt-dev] " Janusz Krzysztofik
2020-05-08 17:54   ` [Intel-gfx] " Chris Wilson
2020-05-08 17:54     ` Chris Wilson
2020-05-11  8:51     ` [Intel-gfx] " Janusz Krzysztofik
2020-05-11  8:51       ` Janusz Krzysztofik
2020-05-11  9:30       ` [Intel-gfx] " Chris Wilson
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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.