All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
@ 2019-04-23 11:32 ` Chris Wilson
  0 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2019-04-23 11:32 UTC (permalink / raw)
  To: intel-gfx; +Cc: igt-dev

Check that we can reorder batches around userspace sempahore waits by
injecting a semaphore that is only released by a later context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/i915/gem_exec_schedule.c | 143 +++++++++++++++++++++++++++++++++
 1 file changed, 143 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 9a0795281..812197770 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -52,6 +52,15 @@
 #define LOCAL_I915_EXEC_BSD_MASK       (3 << LOCAL_I915_EXEC_BSD_SHIFT)
 #define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
 
+#define MI_SEMAPHORE_WAIT		(0x1c << 23)
+#define   MI_SEMAPHORE_POLL             (1 << 15)
+#define   MI_SEMAPHORE_SAD_GT_SDD       (0 << 12)
+#define   MI_SEMAPHORE_SAD_GTE_SDD      (1 << 12)
+#define   MI_SEMAPHORE_SAD_LT_SDD       (2 << 12)
+#define   MI_SEMAPHORE_SAD_LTE_SDD      (3 << 12)
+#define   MI_SEMAPHORE_SAD_EQ_SDD       (4 << 12)
+#define   MI_SEMAPHORE_SAD_NEQ_SDD      (5 << 12)
+
 IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
 
 static inline
@@ -463,6 +472,138 @@ static void semaphore_codependency(int i915)
 	}
 }
 
+static unsigned int offset_in_page(void *addr)
+{
+	return (uintptr_t)addr & 4095;
+}
+
+static void semaphore_resolve(int i915)
+{
+	const uint32_t SEMAPHORE_ADDR = 64 << 10;
+	uint32_t semaphore, outer, inner, *sema;
+	unsigned int engine;
+
+	/*
+	 * Userspace may submit batches that wait upon unresolved
+	 * semaphores. Ideally, we want to put those blocking batches
+	 * to the back of the execution queue if we have something else
+	 * that is ready to run right away. This test exploits a failure
+	 * to reorder batches around a blocking semaphore by submitting
+	 * the release of that semaphore from a later context.
+	 */
+
+	igt_require(gem_scheduler_has_preemption(i915));
+	igt_assert(intel_get_drm_devid(i915) >= 8);
+
+	outer = gem_context_create(i915);
+	inner = gem_context_create(i915);
+
+	semaphore = gem_create(i915, 4096);
+	sema = gem_mmap__wc(i915, semaphore, 0, 4096, PROT_WRITE);
+
+	for_each_physical_engine(i915, engine) {
+		struct drm_i915_gem_exec_object2 obj[3];
+		struct drm_i915_gem_execbuffer2 eb;
+		uint32_t handle, cancel;
+		uint32_t *cs, *map;
+		igt_spin_t *spin;
+
+		if (!gem_can_store_dword(i915, engine))
+			continue;
+
+		spin = __igt_spin_new(i915, .engine = engine);
+		cancel = *spin->batch;
+		igt_spin_end(spin); /* we just want its address for later */
+		gem_sync(i915, spin->handle);
+		*spin->batch = cancel;
+
+		handle = gem_create(i915, 4096);
+		cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
+
+		/* Set semaphore initially to 1 for polling and signaling */
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+		*cs++ = 1;
+
+		/* Wait until another batch writes to our semaphore */
+		*cs++ = MI_SEMAPHORE_WAIT |
+			MI_SEMAPHORE_POLL |
+			MI_SEMAPHORE_SAD_EQ_SDD |
+			(4 - 2);
+		*cs++ = 0;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+
+		/* Then cancel the spinner */
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = spin->obj[1].offset + offset_in_page(spin->batch);
+		*cs++ = 0;
+		*cs++ = MI_BATCH_BUFFER_END;
+
+		*cs++ = MI_BATCH_BUFFER_END;
+		munmap(map, 4096);
+
+		memset(&eb, 0, sizeof(eb));
+
+		/* First up is our spinning semaphore */
+		memset(obj, 0, sizeof(obj));
+		obj[0] = spin->obj[1];
+		obj[1].handle = semaphore;
+		obj[1].offset = SEMAPHORE_ADDR;
+		obj[1].flags = EXEC_OBJECT_PINNED;
+		obj[2].handle = handle;
+		eb.buffer_count = 3;
+		eb.buffers_ptr = to_user_pointer(obj);
+		eb.rsvd1 = outer;
+		gem_execbuf(i915, &eb);
+
+		/* Then add the GPU hang intermediatory */
+		memset(obj, 0, sizeof(obj));
+		obj[0].handle = handle;
+		obj[0].flags = EXEC_OBJECT_WRITE; /* always after semaphore */
+		obj[1] = spin->obj[1];
+		eb.buffer_count = 2;
+		eb.rsvd1 = 0;
+		gem_execbuf(i915, &eb);
+
+		while (READ_ONCE(*sema) == 0)
+			;
+
+		/* Now the semaphore is spinning, cancel it */
+		cancel = gem_create(i915, 4096);
+		cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+		*cs++ = 0;
+		*cs++ = MI_BATCH_BUFFER_END;
+		munmap(map, 4096);
+
+		memset(obj, 0, sizeof(obj));
+		obj[0].handle = semaphore;
+		obj[0].offset = SEMAPHORE_ADDR;
+		obj[0].flags = EXEC_OBJECT_PINNED;
+		obj[1].handle = cancel;
+		eb.buffer_count = 2;
+		eb.rsvd1 = inner;
+		gem_execbuf(i915, &eb);
+		gem_close(i915, cancel);
+
+		gem_sync(i915, handle); /* To hang unless cancel runs! */
+		gem_close(i915, handle);
+		igt_spin_free(i915, spin);
+
+		igt_assert_eq(*sema, 0);
+	}
+
+	munmap(sema, 4096);
+	gem_close(i915, semaphore);
+
+	gem_context_destroy(i915, inner);
+	gem_context_destroy(i915, outer);
+}
+
 static void reorder(int fd, unsigned ring, unsigned flags)
 #define EQUAL 1
 {
@@ -1450,6 +1591,8 @@ igt_main
 			semaphore_userlock(fd);
 		igt_subtest("semaphore-codependency")
 			semaphore_codependency(fd);
+		igt_subtest("semaphore-resolve")
+			semaphore_resolve(fd);
 
 		igt_subtest("smoketest-all")
 			smoketest(fd, ALL_ENGINES, 30);
-- 
2.20.1

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

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

* [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
@ 2019-04-23 11:32 ` Chris Wilson
  0 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2019-04-23 11:32 UTC (permalink / raw)
  To: intel-gfx; +Cc: igt-dev

Check that we can reorder batches around userspace sempahore waits by
injecting a semaphore that is only released by a later context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 tests/i915/gem_exec_schedule.c | 143 +++++++++++++++++++++++++++++++++
 1 file changed, 143 insertions(+)

diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 9a0795281..812197770 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -52,6 +52,15 @@
 #define LOCAL_I915_EXEC_BSD_MASK       (3 << LOCAL_I915_EXEC_BSD_SHIFT)
 #define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
 
+#define MI_SEMAPHORE_WAIT		(0x1c << 23)
+#define   MI_SEMAPHORE_POLL             (1 << 15)
+#define   MI_SEMAPHORE_SAD_GT_SDD       (0 << 12)
+#define   MI_SEMAPHORE_SAD_GTE_SDD      (1 << 12)
+#define   MI_SEMAPHORE_SAD_LT_SDD       (2 << 12)
+#define   MI_SEMAPHORE_SAD_LTE_SDD      (3 << 12)
+#define   MI_SEMAPHORE_SAD_EQ_SDD       (4 << 12)
+#define   MI_SEMAPHORE_SAD_NEQ_SDD      (5 << 12)
+
 IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
 
 static inline
@@ -463,6 +472,138 @@ static void semaphore_codependency(int i915)
 	}
 }
 
+static unsigned int offset_in_page(void *addr)
+{
+	return (uintptr_t)addr & 4095;
+}
+
+static void semaphore_resolve(int i915)
+{
+	const uint32_t SEMAPHORE_ADDR = 64 << 10;
+	uint32_t semaphore, outer, inner, *sema;
+	unsigned int engine;
+
+	/*
+	 * Userspace may submit batches that wait upon unresolved
+	 * semaphores. Ideally, we want to put those blocking batches
+	 * to the back of the execution queue if we have something else
+	 * that is ready to run right away. This test exploits a failure
+	 * to reorder batches around a blocking semaphore by submitting
+	 * the release of that semaphore from a later context.
+	 */
+
+	igt_require(gem_scheduler_has_preemption(i915));
+	igt_assert(intel_get_drm_devid(i915) >= 8);
+
+	outer = gem_context_create(i915);
+	inner = gem_context_create(i915);
+
+	semaphore = gem_create(i915, 4096);
+	sema = gem_mmap__wc(i915, semaphore, 0, 4096, PROT_WRITE);
+
+	for_each_physical_engine(i915, engine) {
+		struct drm_i915_gem_exec_object2 obj[3];
+		struct drm_i915_gem_execbuffer2 eb;
+		uint32_t handle, cancel;
+		uint32_t *cs, *map;
+		igt_spin_t *spin;
+
+		if (!gem_can_store_dword(i915, engine))
+			continue;
+
+		spin = __igt_spin_new(i915, .engine = engine);
+		cancel = *spin->batch;
+		igt_spin_end(spin); /* we just want its address for later */
+		gem_sync(i915, spin->handle);
+		*spin->batch = cancel;
+
+		handle = gem_create(i915, 4096);
+		cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
+
+		/* Set semaphore initially to 1 for polling and signaling */
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+		*cs++ = 1;
+
+		/* Wait until another batch writes to our semaphore */
+		*cs++ = MI_SEMAPHORE_WAIT |
+			MI_SEMAPHORE_POLL |
+			MI_SEMAPHORE_SAD_EQ_SDD |
+			(4 - 2);
+		*cs++ = 0;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+
+		/* Then cancel the spinner */
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = spin->obj[1].offset + offset_in_page(spin->batch);
+		*cs++ = 0;
+		*cs++ = MI_BATCH_BUFFER_END;
+
+		*cs++ = MI_BATCH_BUFFER_END;
+		munmap(map, 4096);
+
+		memset(&eb, 0, sizeof(eb));
+
+		/* First up is our spinning semaphore */
+		memset(obj, 0, sizeof(obj));
+		obj[0] = spin->obj[1];
+		obj[1].handle = semaphore;
+		obj[1].offset = SEMAPHORE_ADDR;
+		obj[1].flags = EXEC_OBJECT_PINNED;
+		obj[2].handle = handle;
+		eb.buffer_count = 3;
+		eb.buffers_ptr = to_user_pointer(obj);
+		eb.rsvd1 = outer;
+		gem_execbuf(i915, &eb);
+
+		/* Then add the GPU hang intermediatory */
+		memset(obj, 0, sizeof(obj));
+		obj[0].handle = handle;
+		obj[0].flags = EXEC_OBJECT_WRITE; /* always after semaphore */
+		obj[1] = spin->obj[1];
+		eb.buffer_count = 2;
+		eb.rsvd1 = 0;
+		gem_execbuf(i915, &eb);
+
+		while (READ_ONCE(*sema) == 0)
+			;
+
+		/* Now the semaphore is spinning, cancel it */
+		cancel = gem_create(i915, 4096);
+		cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
+		*cs++ = MI_STORE_DWORD_IMM;
+		*cs++ = SEMAPHORE_ADDR;
+		*cs++ = 0;
+		*cs++ = 0;
+		*cs++ = MI_BATCH_BUFFER_END;
+		munmap(map, 4096);
+
+		memset(obj, 0, sizeof(obj));
+		obj[0].handle = semaphore;
+		obj[0].offset = SEMAPHORE_ADDR;
+		obj[0].flags = EXEC_OBJECT_PINNED;
+		obj[1].handle = cancel;
+		eb.buffer_count = 2;
+		eb.rsvd1 = inner;
+		gem_execbuf(i915, &eb);
+		gem_close(i915, cancel);
+
+		gem_sync(i915, handle); /* To hang unless cancel runs! */
+		gem_close(i915, handle);
+		igt_spin_free(i915, spin);
+
+		igt_assert_eq(*sema, 0);
+	}
+
+	munmap(sema, 4096);
+	gem_close(i915, semaphore);
+
+	gem_context_destroy(i915, inner);
+	gem_context_destroy(i915, outer);
+}
+
 static void reorder(int fd, unsigned ring, unsigned flags)
 #define EQUAL 1
 {
@@ -1450,6 +1591,8 @@ igt_main
 			semaphore_userlock(fd);
 		igt_subtest("semaphore-codependency")
 			semaphore_codependency(fd);
+		igt_subtest("semaphore-resolve")
+			semaphore_resolve(fd);
 
 		igt_subtest("smoketest-all")
 			smoketest(fd, ALL_ENGINES, 30);
-- 
2.20.1

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

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

* [igt-dev] ✓ Fi.CI.BAT: success for i915/gem_exec_schedule: Exercise resolving of userspace semaphores
  2019-04-23 11:32 ` [igt-dev] " Chris Wilson
  (?)
@ 2019-04-23 14:21 ` Patchwork
  -1 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2019-04-23 14:21 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev

== Series Details ==

Series: i915/gem_exec_schedule: Exercise resolving of userspace semaphores
URL   : https://patchwork.freedesktop.org/series/59822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5971 -> IGTPW_2903
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/59822/revisions/1/mbox/

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_selftest@live_contexts:
    - fi-skl-gvtdvm:      [PASS][1] -> [DMESG-FAIL][2] ([fdo#110235 ])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html

  * igt@i915_selftest@live_execlists:
    - fi-apl-guc:         [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] / [fdo#109720])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-apl-guc/igt@i915_selftest@live_execlists.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/fi-apl-guc/igt@i915_selftest@live_execlists.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-byt-clapper:     [PASS][5] -> [FAIL][6] ([fdo#103167])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-byt-clapper/igt@kms_frontbuffer_tracking@basic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/fi-byt-clapper/igt@kms_frontbuffer_tracking@basic.html

  * igt@runner@aborted:
    - fi-apl-guc:         NOTRUN -> [FAIL][7] ([fdo#108622] / [fdo#109720])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/fi-apl-guc/igt@runner@aborted.html

  
#### Possible fixes ####

  * igt@kms_flip@basic-flip-vs-wf_vblank:
    - fi-bwr-2160:        [FAIL][8] ([fdo#100368]) -> [PASS][9]
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html

  
  [fdo#100368]: https://bugs.freedesktop.org/show_bug.cgi?id=100368
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
  [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
  [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 


Participating hosts (50 -> 40)
------------------------------

  Missing    (10): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 fi-icl-y fi-bdw-samus 


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

  * IGT: IGT_4959 -> IGTPW_2903

  CI_DRM_5971: e91b848a66e8672c48ea65d082b260f13f2c86b9 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2903: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/
  IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0b3074 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_exec_schedule@semaphore-resolve

== Logs ==

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

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

* [igt-dev] ✓ Fi.CI.IGT: success for i915/gem_exec_schedule: Exercise resolving of userspace semaphores
  2019-04-23 11:32 ` [igt-dev] " Chris Wilson
  (?)
  (?)
@ 2019-04-23 17:06 ` Patchwork
  -1 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2019-04-23 17:06 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev

== Series Details ==

Series: i915/gem_exec_schedule: Exercise resolving of userspace semaphores
URL   : https://patchwork.freedesktop.org/series/59822/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5971_full -> IGTPW_2903_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/59822/revisions/1/mbox/

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

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

### IGT changes ###

#### Possible regressions ####

  * {igt@gem_exec_schedule@semaphore-resolve} (NEW):
    - shard-glk:          NOTRUN -> [FAIL][1]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-glk2/igt@gem_exec_schedule@semaphore-resolve.html
    - shard-kbl:          NOTRUN -> [FAIL][2]
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-kbl1/igt@gem_exec_schedule@semaphore-resolve.html
    - shard-iclb:         NOTRUN -> [FAIL][3]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb6/igt@gem_exec_schedule@semaphore-resolve.html
    - shard-apl:          NOTRUN -> [FAIL][4]
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-apl1/igt@gem_exec_schedule@semaphore-resolve.html

  
New tests
---------

  New tests have been introduced between CI_DRM_5971_full and IGTPW_2903_full:

### New IGT tests (1) ###

  * igt@gem_exec_schedule@semaphore-resolve:
    - Statuses : 4 fail(s) 2 skip(s)
    - Exec time: [0.0, 8.25] s

  

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_isolation@bcs0-s3:
    - shard-apl:          [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl3/igt@gem_ctx_isolation@bcs0-s3.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-apl6/igt@gem_ctx_isolation@bcs0-s3.html

  * {igt@gem_exec_schedule@semaphore-resolve} (NEW):
    - shard-snb:          NOTRUN -> [SKIP][7] ([fdo#109271])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-snb1/igt@gem_exec_schedule@semaphore-resolve.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-kbl:          [PASS][8] -> [SKIP][9] ([fdo#109271])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-kbl1/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-kbl5/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@kms_cursor_crc@cursor-64x64-suspend:
    - shard-apl:          [PASS][10] -> [FAIL][11] ([fdo#103232])
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl1/igt@kms_cursor_crc@cursor-64x64-suspend.html
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-apl5/igt@kms_cursor_crc@cursor-64x64-suspend.html
    - shard-kbl:          [PASS][12] -> [FAIL][13] ([fdo#103232])
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-kbl3/igt@kms_cursor_crc@cursor-64x64-suspend.html
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-kbl4/igt@kms_cursor_crc@cursor-64x64-suspend.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
    - shard-glk:          [PASS][14] -> [FAIL][15] ([fdo#104873])
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk7/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
    - shard-glk:          [PASS][16] -> [FAIL][17] ([fdo#105363])
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
    - shard-iclb:         [PASS][18] -> [FAIL][19] ([fdo#103167]) +6 similar issues
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt.html
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-plflip-blt:
    - shard-hsw:          NOTRUN -> [SKIP][20] ([fdo#109271]) +8 similar issues
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-hsw8/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-plflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
    - shard-hsw:          NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#109278]) +1 similar issue
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-hsw6/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
    - shard-iclb:         [PASS][22] -> [FAIL][23] ([fdo#103166])
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-y.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb4/igt@kms_plane_lowres@pipe-a-tiling-y.html

  * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
    - shard-glk:          [PASS][24] -> [SKIP][25] ([fdo#109271] / [fdo#109278]) +1 similar issue
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk9/igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-glk1/igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [PASS][26] -> [SKIP][27] ([fdo#109642]) +1 similar issue
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb6/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [PASS][28] -> [FAIL][29] ([fdo#99912])
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-kbl4/igt@kms_setmode@basic.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-kbl4/igt@kms_setmode@basic.html

  
#### Possible fixes ####

  * igt@gem_tiled_swapping@non-threaded:
    - shard-iclb:         [FAIL][30] ([fdo#108686]) -> [PASS][31]
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb1/igt@gem_tiled_swapping@non-threaded.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb6/igt@gem_tiled_swapping@non-threaded.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
    - shard-snb:          [SKIP][32] ([fdo#109271]) -> [PASS][33]
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-snb7/igt@i915_pm_rc6_residency@rc6-accuracy.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-snb6/igt@i915_pm_rc6_residency@rc6-accuracy.html

  * igt@i915_pm_rpm@i2c:
    - shard-iclb:         [FAIL][34] ([fdo#104097]) -> [PASS][35]
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb8/igt@i915_pm_rpm@i2c.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb6/igt@i915_pm_rpm@i2c.html

  * igt@i915_suspend@fence-restore-untiled:
    - shard-apl:          [DMESG-WARN][36] ([fdo#108566]) -> [PASS][37] +7 similar issues
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-apl7/igt@i915_suspend@fence-restore-untiled.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-apl8/igt@i915_suspend@fence-restore-untiled.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-hsw:          [INCOMPLETE][38] ([fdo#103540]) -> [PASS][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-hsw7/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-rte:
    - shard-iclb:         [FAIL][40] ([fdo#103167] / [fdo#110378]) -> [PASS][41]
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-rte.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb3/igt@kms_frontbuffer_tracking@fbc-1p-rte.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite:
    - shard-glk:          [FAIL][42] ([fdo#103167]) -> [PASS][43]
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-glk8/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-glk4/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-pwrite.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
    - shard-iclb:         [FAIL][44] ([fdo#103167]) -> [PASS][45] +3 similar issues
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [FAIL][46] ([fdo#103166]) -> [PASS][47]
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb4/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
    - shard-iclb:         [SKIP][48] ([fdo#109441]) -> [PASS][49] +2 similar issues
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5971/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html

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

  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
  [fdo#104097]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
  [fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
  [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
  [fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
  [fdo#108686]: https://bugs.freedesktop.org/show_bug.cgi?id=108686
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#110378]: https://bugs.freedesktop.org/show_bug.cgi?id=110378
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912


Participating hosts (10 -> 6)
------------------------------

  Missing    (4): pig-skl-6260u shard-skl pig-hsw-4770r pig-glk-j5005 


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

  * IGT: IGT_4959 -> IGTPW_2903
  * Piglit: piglit_4509 -> None

  CI_DRM_5971: e91b848a66e8672c48ea65d082b260f13f2c86b9 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2903: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2903/
  IGT_4959: 504367d33b787de2ba8e007a5b620cfd6f0b3074 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

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

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

* Re: [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
  2019-04-23 11:32 ` [igt-dev] " Chris Wilson
@ 2019-04-25 10:40   ` Mika Kuoppala
  -1 siblings, 0 replies; 8+ messages in thread
From: Mika Kuoppala @ 2019-04-25 10:40 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: igt-dev

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Check that we can reorder batches around userspace sempahore waits by

semaphore

> injecting a semaphore that is only released by a later context.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  tests/i915/gem_exec_schedule.c | 143 +++++++++++++++++++++++++++++++++
>  1 file changed, 143 insertions(+)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 9a0795281..812197770 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -52,6 +52,15 @@
>  #define LOCAL_I915_EXEC_BSD_MASK       (3 << LOCAL_I915_EXEC_BSD_SHIFT)
>  #define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
>  
> +#define MI_SEMAPHORE_WAIT		(0x1c << 23)
> +#define   MI_SEMAPHORE_POLL             (1 << 15)
> +#define   MI_SEMAPHORE_SAD_GT_SDD       (0 << 12)
> +#define   MI_SEMAPHORE_SAD_GTE_SDD      (1 << 12)
> +#define   MI_SEMAPHORE_SAD_LT_SDD       (2 << 12)
> +#define   MI_SEMAPHORE_SAD_LTE_SDD      (3 << 12)
> +#define   MI_SEMAPHORE_SAD_EQ_SDD       (4 << 12)
> +#define   MI_SEMAPHORE_SAD_NEQ_SDD      (5 << 12)
> +
>  IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
>  
>  static inline
> @@ -463,6 +472,138 @@ static void semaphore_codependency(int i915)
>  	}
>  }
>  
> +static unsigned int offset_in_page(void *addr)
> +{
> +	return (uintptr_t)addr & 4095;
> +}
> +
> +static void semaphore_resolve(int i915)
> +{
> +	const uint32_t SEMAPHORE_ADDR = 64 << 10;
> +	uint32_t semaphore, outer, inner, *sema;
> +	unsigned int engine;
> +
> +	/*
> +	 * Userspace may submit batches that wait upon unresolved
> +	 * semaphores. Ideally, we want to put those blocking batches
> +	 * to the back of the execution queue if we have something else
> +	 * that is ready to run right away. This test exploits a failure
> +	 * to reorder batches around a blocking semaphore by submitting
> +	 * the release of that semaphore from a later context.
> +	 */
> +
> +	igt_require(gem_scheduler_has_preemption(i915));
> +	igt_assert(intel_get_drm_devid(i915) >= 8);
> +
> +	outer = gem_context_create(i915);
> +	inner = gem_context_create(i915);
> +
> +	semaphore = gem_create(i915, 4096);

For the uninitiated, the assumption that first object
is always at ppgtt address zero, is not so obvious. But this
is not the first test to make that assumption nor the last.

> +	sema = gem_mmap__wc(i915, semaphore, 0, 4096, PROT_WRITE);
> +
> +	for_each_physical_engine(i915, engine) {
> +		struct drm_i915_gem_exec_object2 obj[3];
> +		struct drm_i915_gem_execbuffer2 eb;
> +		uint32_t handle, cancel;
> +		uint32_t *cs, *map;
> +		igt_spin_t *spin;
> +
> +		if (!gem_can_store_dword(i915, engine))
> +			continue;
> +
> +		spin = __igt_spin_new(i915, .engine = engine);
> +		cancel = *spin->batch;
> +		igt_spin_end(spin); /* we just want its address for later */

I do see igt_spin_reset in here. And it also makes me now think
if that I should check if we reset as a part of end.

> +		gem_sync(i915, spin->handle);
> +		*spin->batch = cancel;
> +
> +		handle = gem_create(i915, 4096);
> +		cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
> +
> +		/* Set semaphore initially to 1 for polling and signaling */
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +		*cs++ = 1;
> +
> +		/* Wait until another batch writes to our semaphore */
> +		*cs++ = MI_SEMAPHORE_WAIT |
> +			MI_SEMAPHORE_POLL |
> +			MI_SEMAPHORE_SAD_EQ_SDD |
> +			(4 - 2);
> +		*cs++ = 0;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +
> +		/* Then cancel the spinner */
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = spin->obj[1].offset + offset_in_page(spin->batch);
> +		*cs++ = 0;
> +		*cs++ = MI_BATCH_BUFFER_END;
> +
> +		*cs++ = MI_BATCH_BUFFER_END;
> +		munmap(map, 4096);
> +
> +		memset(&eb, 0, sizeof(eb));
> +
> +		/* First up is our spinning semaphore */
> +		memset(obj, 0, sizeof(obj));
> +		obj[0] = spin->obj[1];
> +		obj[1].handle = semaphore;
> +		obj[1].offset = SEMAPHORE_ADDR;
> +		obj[1].flags = EXEC_OBJECT_PINNED;
> +		obj[2].handle = handle;
> +		eb.buffer_count = 3;
> +		eb.buffers_ptr = to_user_pointer(obj);
> +		eb.rsvd1 = outer;
> +		gem_execbuf(i915, &eb);
> +
> +		/* Then add the GPU hang intermediatory */
> +		memset(obj, 0, sizeof(obj));
> +		obj[0].handle = handle;
> +		obj[0].flags = EXEC_OBJECT_WRITE; /* always after semaphore */
> +		obj[1] = spin->obj[1];
> +		eb.buffer_count = 2;
> +		eb.rsvd1 = 0;
> +		gem_execbuf(i915, &eb);
> +
> +		while (READ_ONCE(*sema) == 0)

Dreaming of generalizing the batch has started signalling
and the spinner along with it. But not a topic of this patch.

> +			;
> +
> +		/* Now the semaphore is spinning, cancel it */
> +		cancel = gem_create(i915, 4096);
> +		cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +		*cs++ = 0;
> +		*cs++ = MI_BATCH_BUFFER_END;
> +		munmap(map, 4096);
> +
> +		memset(obj, 0, sizeof(obj));
> +		obj[0].handle = semaphore;
> +		obj[0].offset = SEMAPHORE_ADDR;
> +		obj[0].flags = EXEC_OBJECT_PINNED;
> +		obj[1].handle = cancel;
> +		eb.buffer_count = 2;
> +		eb.rsvd1 = inner;
> +		gem_execbuf(i915, &eb);
> +		gem_close(i915, cancel);
> +
> +		gem_sync(i915, handle); /* To hang unless cancel runs! */

Ok, well I am not exactly sure about the march order on here
onwards. I mean that if the timeslicing is not yet there,
we need to embrace the hang as a success?

Tho perhaps the march...merge order is better discussed
in the context of actual kernel side patch.

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>


> +		gem_close(i915, handle);
> +		igt_spin_free(i915, spin);
> +
> +		igt_assert_eq(*sema, 0);
> +	}
> +
> +	munmap(sema, 4096);
> +	gem_close(i915, semaphore);
> +
> +	gem_context_destroy(i915, inner);
> +	gem_context_destroy(i915, outer);
> +}
> +
>  static void reorder(int fd, unsigned ring, unsigned flags)
>  #define EQUAL 1
>  {
> @@ -1450,6 +1591,8 @@ igt_main
>  			semaphore_userlock(fd);
>  		igt_subtest("semaphore-codependency")
>  			semaphore_codependency(fd);
> +		igt_subtest("semaphore-resolve")
> +			semaphore_resolve(fd);
>  
>  		igt_subtest("smoketest-all")
>  			smoketest(fd, ALL_ENGINES, 30);
> -- 
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
@ 2019-04-25 10:40   ` Mika Kuoppala
  0 siblings, 0 replies; 8+ messages in thread
From: Mika Kuoppala @ 2019-04-25 10:40 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: igt-dev

Chris Wilson <chris@chris-wilson.co.uk> writes:

> Check that we can reorder batches around userspace sempahore waits by

semaphore

> injecting a semaphore that is only released by a later context.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  tests/i915/gem_exec_schedule.c | 143 +++++++++++++++++++++++++++++++++
>  1 file changed, 143 insertions(+)
>
> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
> index 9a0795281..812197770 100644
> --- a/tests/i915/gem_exec_schedule.c
> +++ b/tests/i915/gem_exec_schedule.c
> @@ -52,6 +52,15 @@
>  #define LOCAL_I915_EXEC_BSD_MASK       (3 << LOCAL_I915_EXEC_BSD_SHIFT)
>  #define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
>  
> +#define MI_SEMAPHORE_WAIT		(0x1c << 23)
> +#define   MI_SEMAPHORE_POLL             (1 << 15)
> +#define   MI_SEMAPHORE_SAD_GT_SDD       (0 << 12)
> +#define   MI_SEMAPHORE_SAD_GTE_SDD      (1 << 12)
> +#define   MI_SEMAPHORE_SAD_LT_SDD       (2 << 12)
> +#define   MI_SEMAPHORE_SAD_LTE_SDD      (3 << 12)
> +#define   MI_SEMAPHORE_SAD_EQ_SDD       (4 << 12)
> +#define   MI_SEMAPHORE_SAD_NEQ_SDD      (5 << 12)
> +
>  IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
>  
>  static inline
> @@ -463,6 +472,138 @@ static void semaphore_codependency(int i915)
>  	}
>  }
>  
> +static unsigned int offset_in_page(void *addr)
> +{
> +	return (uintptr_t)addr & 4095;
> +}
> +
> +static void semaphore_resolve(int i915)
> +{
> +	const uint32_t SEMAPHORE_ADDR = 64 << 10;
> +	uint32_t semaphore, outer, inner, *sema;
> +	unsigned int engine;
> +
> +	/*
> +	 * Userspace may submit batches that wait upon unresolved
> +	 * semaphores. Ideally, we want to put those blocking batches
> +	 * to the back of the execution queue if we have something else
> +	 * that is ready to run right away. This test exploits a failure
> +	 * to reorder batches around a blocking semaphore by submitting
> +	 * the release of that semaphore from a later context.
> +	 */
> +
> +	igt_require(gem_scheduler_has_preemption(i915));
> +	igt_assert(intel_get_drm_devid(i915) >= 8);
> +
> +	outer = gem_context_create(i915);
> +	inner = gem_context_create(i915);
> +
> +	semaphore = gem_create(i915, 4096);

For the uninitiated, the assumption that first object
is always at ppgtt address zero, is not so obvious. But this
is not the first test to make that assumption nor the last.

> +	sema = gem_mmap__wc(i915, semaphore, 0, 4096, PROT_WRITE);
> +
> +	for_each_physical_engine(i915, engine) {
> +		struct drm_i915_gem_exec_object2 obj[3];
> +		struct drm_i915_gem_execbuffer2 eb;
> +		uint32_t handle, cancel;
> +		uint32_t *cs, *map;
> +		igt_spin_t *spin;
> +
> +		if (!gem_can_store_dword(i915, engine))
> +			continue;
> +
> +		spin = __igt_spin_new(i915, .engine = engine);
> +		cancel = *spin->batch;
> +		igt_spin_end(spin); /* we just want its address for later */

I do see igt_spin_reset in here. And it also makes me now think
if that I should check if we reset as a part of end.

> +		gem_sync(i915, spin->handle);
> +		*spin->batch = cancel;
> +
> +		handle = gem_create(i915, 4096);
> +		cs = map = gem_mmap__cpu(i915, handle, 0, 4096, PROT_WRITE);
> +
> +		/* Set semaphore initially to 1 for polling and signaling */
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +		*cs++ = 1;
> +
> +		/* Wait until another batch writes to our semaphore */
> +		*cs++ = MI_SEMAPHORE_WAIT |
> +			MI_SEMAPHORE_POLL |
> +			MI_SEMAPHORE_SAD_EQ_SDD |
> +			(4 - 2);
> +		*cs++ = 0;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +
> +		/* Then cancel the spinner */
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = spin->obj[1].offset + offset_in_page(spin->batch);
> +		*cs++ = 0;
> +		*cs++ = MI_BATCH_BUFFER_END;
> +
> +		*cs++ = MI_BATCH_BUFFER_END;
> +		munmap(map, 4096);
> +
> +		memset(&eb, 0, sizeof(eb));
> +
> +		/* First up is our spinning semaphore */
> +		memset(obj, 0, sizeof(obj));
> +		obj[0] = spin->obj[1];
> +		obj[1].handle = semaphore;
> +		obj[1].offset = SEMAPHORE_ADDR;
> +		obj[1].flags = EXEC_OBJECT_PINNED;
> +		obj[2].handle = handle;
> +		eb.buffer_count = 3;
> +		eb.buffers_ptr = to_user_pointer(obj);
> +		eb.rsvd1 = outer;
> +		gem_execbuf(i915, &eb);
> +
> +		/* Then add the GPU hang intermediatory */
> +		memset(obj, 0, sizeof(obj));
> +		obj[0].handle = handle;
> +		obj[0].flags = EXEC_OBJECT_WRITE; /* always after semaphore */
> +		obj[1] = spin->obj[1];
> +		eb.buffer_count = 2;
> +		eb.rsvd1 = 0;
> +		gem_execbuf(i915, &eb);
> +
> +		while (READ_ONCE(*sema) == 0)

Dreaming of generalizing the batch has started signalling
and the spinner along with it. But not a topic of this patch.

> +			;
> +
> +		/* Now the semaphore is spinning, cancel it */
> +		cancel = gem_create(i915, 4096);
> +		cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> +		*cs++ = MI_STORE_DWORD_IMM;
> +		*cs++ = SEMAPHORE_ADDR;
> +		*cs++ = 0;
> +		*cs++ = 0;
> +		*cs++ = MI_BATCH_BUFFER_END;
> +		munmap(map, 4096);
> +
> +		memset(obj, 0, sizeof(obj));
> +		obj[0].handle = semaphore;
> +		obj[0].offset = SEMAPHORE_ADDR;
> +		obj[0].flags = EXEC_OBJECT_PINNED;
> +		obj[1].handle = cancel;
> +		eb.buffer_count = 2;
> +		eb.rsvd1 = inner;
> +		gem_execbuf(i915, &eb);
> +		gem_close(i915, cancel);
> +
> +		gem_sync(i915, handle); /* To hang unless cancel runs! */

Ok, well I am not exactly sure about the march order on here
onwards. I mean that if the timeslicing is not yet there,
we need to embrace the hang as a success?

Tho perhaps the march...merge order is better discussed
in the context of actual kernel side patch.

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>


> +		gem_close(i915, handle);
> +		igt_spin_free(i915, spin);
> +
> +		igt_assert_eq(*sema, 0);
> +	}
> +
> +	munmap(sema, 4096);
> +	gem_close(i915, semaphore);
> +
> +	gem_context_destroy(i915, inner);
> +	gem_context_destroy(i915, outer);
> +}
> +
>  static void reorder(int fd, unsigned ring, unsigned flags)
>  #define EQUAL 1
>  {
> @@ -1450,6 +1591,8 @@ igt_main
>  			semaphore_userlock(fd);
>  		igt_subtest("semaphore-codependency")
>  			semaphore_codependency(fd);
> +		igt_subtest("semaphore-resolve")
> +			semaphore_resolve(fd);
>  
>  		igt_subtest("smoketest-all")
>  			smoketest(fd, ALL_ENGINES, 30);
> -- 
> 2.20.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

* Re: [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
  2019-04-25 10:40   ` [igt-dev] " Mika Kuoppala
@ 2019-04-25 11:16     ` Chris Wilson
  -1 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2019-04-25 11:16 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx; +Cc: igt-dev

Quoting Mika Kuoppala (2019-04-25 11:40:13)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> > +             /* Now the semaphore is spinning, cancel it */
> > +             cancel = gem_create(i915, 4096);
> > +             cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> > +             *cs++ = MI_STORE_DWORD_IMM;
> > +             *cs++ = SEMAPHORE_ADDR;
> > +             *cs++ = 0;
> > +             *cs++ = 0;
> > +             *cs++ = MI_BATCH_BUFFER_END;
> > +             munmap(map, 4096);
> > +
> > +             memset(obj, 0, sizeof(obj));
> > +             obj[0].handle = semaphore;
> > +             obj[0].offset = SEMAPHORE_ADDR;
> > +             obj[0].flags = EXEC_OBJECT_PINNED;
> > +             obj[1].handle = cancel;
> > +             eb.buffer_count = 2;
> > +             eb.rsvd1 = inner;
> > +             gem_execbuf(i915, &eb);
> > +             gem_close(i915, cancel);
> > +
> > +             gem_sync(i915, handle); /* To hang unless cancel runs! */
> 
> Ok, well I am not exactly sure about the march order on here
> onwards. I mean that if the timeslicing is not yet there,
> we need to embrace the hang as a success?

It's just a known failure to be fixed. So long as it doesn't flip-flop,
only those looking at the failure reports (not the issues listed in the
CI summaries), cibuglog and bugzilla get annoyed.
 
> Tho perhaps the march...merge order is better discussed
> in the context of actual kernel side patch.

Much nicer to be able to point to a test failure being fixed, gives the
green jollies.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores
@ 2019-04-25 11:16     ` Chris Wilson
  0 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2019-04-25 11:16 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx; +Cc: igt-dev

Quoting Mika Kuoppala (2019-04-25 11:40:13)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> > +             /* Now the semaphore is spinning, cancel it */
> > +             cancel = gem_create(i915, 4096);
> > +             cs = map = gem_mmap__cpu(i915, cancel, 0, 4096, PROT_WRITE);
> > +             *cs++ = MI_STORE_DWORD_IMM;
> > +             *cs++ = SEMAPHORE_ADDR;
> > +             *cs++ = 0;
> > +             *cs++ = 0;
> > +             *cs++ = MI_BATCH_BUFFER_END;
> > +             munmap(map, 4096);
> > +
> > +             memset(obj, 0, sizeof(obj));
> > +             obj[0].handle = semaphore;
> > +             obj[0].offset = SEMAPHORE_ADDR;
> > +             obj[0].flags = EXEC_OBJECT_PINNED;
> > +             obj[1].handle = cancel;
> > +             eb.buffer_count = 2;
> > +             eb.rsvd1 = inner;
> > +             gem_execbuf(i915, &eb);
> > +             gem_close(i915, cancel);
> > +
> > +             gem_sync(i915, handle); /* To hang unless cancel runs! */
> 
> Ok, well I am not exactly sure about the march order on here
> onwards. I mean that if the timeslicing is not yet there,
> we need to embrace the hang as a success?

It's just a known failure to be fixed. So long as it doesn't flip-flop,
only those looking at the failure reports (not the issues listed in the
CI summaries), cibuglog and bugzilla get annoyed.
 
> Tho perhaps the march...merge order is better discussed
> in the context of actual kernel side patch.

Much nicer to be able to point to a test failure being fixed, gives the
green jollies.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

end of thread, other threads:[~2019-04-25 11:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-23 11:32 [PATCH i-g-t] i915/gem_exec_schedule: Exercise resolving of userspace semaphores Chris Wilson
2019-04-23 11:32 ` [igt-dev] " Chris Wilson
2019-04-23 14:21 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-04-23 17:06 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2019-04-25 10:40 ` [PATCH i-g-t] " Mika Kuoppala
2019-04-25 10:40   ` [igt-dev] " Mika Kuoppala
2019-04-25 11:16   ` Chris Wilson
2019-04-25 11:16     ` [igt-dev] " Chris Wilson

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.