public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
* [igt-dev] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies
@ 2019-11-27 14:50 Chris Wilson
  2019-11-27 15:08 ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Chris Wilson @ 2019-11-27 14:50 UTC (permalink / raw)
  To: intel-gfx; +Cc: igt-dev, Tvrtko Ursulin

Check that the submit fence couples into the dependency chain so that
the bonded pair cannot over take any of the earlier requests.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 tests/i915/gem_exec_balancer.c | 88 ++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 86028cfdd..ff5bd0134 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -855,6 +855,91 @@ static void bonded_slice(int i915)
 	munmap(stop, 4096);
 }
 
+static void bonded_chain(int i915)
+{
+	struct drm_i915_gem_exec_object2 batch = {
+		.handle = batch_create(i915),
+	};
+	uint32_t ctx;
+
+	/*
+	 * Given batches A, B and B', where B and B' are a bonded pair, with
+	 * B' depending on B with a submit fence and B depending on A as
+	 * an ordinary fence; prove B' cannot complete before A.
+	 */
+
+	ctx = gem_context_create(i915);
+
+	for (int class = 0; class < 32; class++) {
+		struct i915_engine_class_instance *siblings;
+		struct drm_i915_gem_execbuffer2 execbuf = {
+			.buffers_ptr = to_user_pointer(&batch),
+			.buffer_count = 1,
+			.rsvd1 = ctx,
+		};
+		unsigned int count;
+		igt_spin_t *spin;
+
+		siblings = list_engines(i915, 1u << class, &count);
+		if (!siblings)
+			continue;
+
+		if (count < 2) {
+			free(siblings);
+			continue;
+		}
+
+		/* A: spin forever on engine 1 */
+		set_load_balancer(i915, ctx, siblings, count, NULL);
+		spin = igt_spin_new(i915,
+				    .ctx = ctx,
+				    .engine = 1,
+				    .flags = (IGT_SPIN_POLL_RUN |
+					      IGT_SPIN_FENCE_OUT));
+		igt_spin_busywait_until_started(spin);
+
+		/* B: waits for A on engine 2 */
+		set_load_balancer(i915, ctx, siblings, count, NULL);
+		execbuf.rsvd2 = spin->out_fence;
+		execbuf.flags = I915_EXEC_FENCE_IN | I915_EXEC_FENCE_OUT;
+		execbuf.flags |= 2; /* opposite engine to spinner */
+		gem_execbuf_wr(i915, &execbuf);
+
+		/* B': run in parallel with B on engine 1, i.e. not before A! */
+		set_load_balancer(i915, ctx, siblings, count, NULL);
+		execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
+		execbuf.flags |= 1; /* same engine as spinner */
+		execbuf.rsvd2 >>= 32;
+		gem_execbuf_wr(i915, &execbuf);
+
+		/* Wait for any magic timeslicing or preemptions... */
+		igt_assert_eq(sync_fence_wait(execbuf.rsvd2 >> 32, 1000),
+			      -ETIME);
+
+		igt_debugfs_dump(i915, "i915_engine_info");
+
+		/*
+		 * ... which should not have happened, so everything is still
+		 * waiting on the spinner
+		 */
+		igt_assert_eq(sync_fence_status(spin->out_fence), 0);
+		igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 0);
+		igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 0);
+
+		igt_spin_free(i915, spin);
+		gem_sync(i915, batch.handle);
+
+		igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 1);
+		igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
+
+		close(execbuf.rsvd2);
+		close(execbuf.rsvd2 >> 32);
+	}
+
+	gem_context_destroy(i915, ctx);
+	gem_close(i915, batch.handle);
+}
+
 static void indices(int i915)
 {
 	I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, I915_EXEC_RING_MASK + 1);
@@ -1580,6 +1665,9 @@ igt_main
 	igt_subtest("bonded-slice")
 		bonded_slice(i915);
 
+	igt_subtest("bonded-chain")
+		bonded_chain(i915);
+
 	igt_fixture {
 		igt_stop_hang_detector();
 	}
-- 
2.24.0

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

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

* Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies
  2019-11-27 14:50 [igt-dev] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies Chris Wilson
@ 2019-11-27 15:08 ` Tvrtko Ursulin
  2019-11-27 15:15   ` Chris Wilson
  2019-11-27 15:17 ` [igt-dev] ✗ GitLab.Pipeline: failure for " Patchwork
  2019-11-27 15:25 ` [igt-dev] ✗ Fi.CI.BAT: " Patchwork
  2 siblings, 1 reply; 6+ messages in thread
From: Tvrtko Ursulin @ 2019-11-27 15:08 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: igt-dev


On 27/11/2019 14:50, Chris Wilson wrote:
> Check that the submit fence couples into the dependency chain so that
> the bonded pair cannot over take any of the earlier requests.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   tests/i915/gem_exec_balancer.c | 88 ++++++++++++++++++++++++++++++++++
>   1 file changed, 88 insertions(+)
> 
> diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> index 86028cfdd..ff5bd0134 100644
> --- a/tests/i915/gem_exec_balancer.c
> +++ b/tests/i915/gem_exec_balancer.c
> @@ -855,6 +855,91 @@ static void bonded_slice(int i915)
>   	munmap(stop, 4096);
>   }
>   
> +static void bonded_chain(int i915)
> +{
> +	struct drm_i915_gem_exec_object2 batch = {
> +		.handle = batch_create(i915),
> +	};
> +	uint32_t ctx;
> +
> +	/*
> +	 * Given batches A, B and B', where B and B' are a bonded pair, with
> +	 * B' depending on B with a submit fence and B depending on A as
> +	 * an ordinary fence; prove B' cannot complete before A.
> +	 */
> +
> +	ctx = gem_context_create(i915);
> +
> +	for (int class = 0; class < 32; class++) {
> +		struct i915_engine_class_instance *siblings;
> +		struct drm_i915_gem_execbuffer2 execbuf = {
> +			.buffers_ptr = to_user_pointer(&batch),
> +			.buffer_count = 1,
> +			.rsvd1 = ctx,
> +		};
> +		unsigned int count;
> +		igt_spin_t *spin;
> +
> +		siblings = list_engines(i915, 1u << class, &count);
> +		if (!siblings)
> +			continue;
> +
> +		if (count < 2) {
> +			free(siblings);
> +			continue;
> +		}
> +
> +		/* A: spin forever on engine 1 */
> +		set_load_balancer(i915, ctx, siblings, count, NULL);
> +		spin = igt_spin_new(i915,
> +				    .ctx = ctx,
> +				    .engine = 1,
> +				    .flags = (IGT_SPIN_POLL_RUN |
> +					      IGT_SPIN_FENCE_OUT));
> +		igt_spin_busywait_until_started(spin);
> +
> +		/* B: waits for A on engine 2 */
> +		set_load_balancer(i915, ctx, siblings, count, NULL);
> +		execbuf.rsvd2 = spin->out_fence;
> +		execbuf.flags = I915_EXEC_FENCE_IN | I915_EXEC_FENCE_OUT;
> +		execbuf.flags |= 2; /* opposite engine to spinner */

Why or?

> +		gem_execbuf_wr(i915, &execbuf);
> +
> +		/* B': run in parallel with B on engine 1, i.e. not before A! */
> +		set_load_balancer(i915, ctx, siblings, count, NULL);

Why are you repeating the same set_load_balancer calls?

> +		execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
> +		execbuf.flags |= 1; /* same engine as spinner */

Engine 3? But there are only two engines in the map, plus the virtual. 
So 0, 1, 2 - how does this work for you?

> +		execbuf.rsvd2 >>= 32;
> +		gem_execbuf_wr(i915, &execbuf);
> +
> +		/* Wait for any magic timeslicing or preemptions... */
> +		igt_assert_eq(sync_fence_wait(execbuf.rsvd2 >> 32, 1000),
> +			      -ETIME);
> +
> +		igt_debugfs_dump(i915, "i915_engine_info");
> +
> +		/*
> +		 * ... which should not have happened, so everything is still
> +		 * waiting on the spinner
> +		 */
> +		igt_assert_eq(sync_fence_status(spin->out_fence), 0);
> +		igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 0);
> +		igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 0);
> +
> +		igt_spin_free(i915, spin);
> +		gem_sync(i915, batch.handle);
> +
> +		igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 1);
> +		igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
> +
> +		close(execbuf.rsvd2);
> +		close(execbuf.rsvd2 >> 32);
> +	}

How evil to lower ctx prio for A only?

> +
> +	gem_context_destroy(i915, ctx);
> +	gem_close(i915, batch.handle);
> +}
> +
>   static void indices(int i915)
>   {
>   	I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, I915_EXEC_RING_MASK + 1);
> @@ -1580,6 +1665,9 @@ igt_main
>   	igt_subtest("bonded-slice")
>   		bonded_slice(i915);
>   
> +	igt_subtest("bonded-chain")
> +		bonded_chain(i915);
> +
>   	igt_fixture {
>   		igt_stop_hang_detector();
>   	}
> 

Regards,

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

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

* Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies
  2019-11-27 15:08 ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin
@ 2019-11-27 15:15   ` Chris Wilson
  2019-11-27 15:20     ` Tvrtko Ursulin
  0 siblings, 1 reply; 6+ messages in thread
From: Chris Wilson @ 2019-11-27 15:15 UTC (permalink / raw)
  To: Tvrtko Ursulin, intel-gfx; +Cc: igt-dev

Quoting Tvrtko Ursulin (2019-11-27 15:08:25)
> 
> On 27/11/2019 14:50, Chris Wilson wrote:
> > Check that the submit fence couples into the dependency chain so that
> > the bonded pair cannot over take any of the earlier requests.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > ---
> >   tests/i915/gem_exec_balancer.c | 88 ++++++++++++++++++++++++++++++++++
> >   1 file changed, 88 insertions(+)
> > 
> > diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> > index 86028cfdd..ff5bd0134 100644
> > --- a/tests/i915/gem_exec_balancer.c
> > +++ b/tests/i915/gem_exec_balancer.c
> > @@ -855,6 +855,91 @@ static void bonded_slice(int i915)
> >       munmap(stop, 4096);
> >   }
> >   
> > +static void bonded_chain(int i915)
> > +{
> > +     struct drm_i915_gem_exec_object2 batch = {
> > +             .handle = batch_create(i915),
> > +     };
> > +     uint32_t ctx;
> > +
> > +     /*
> > +      * Given batches A, B and B', where B and B' are a bonded pair, with
> > +      * B' depending on B with a submit fence and B depending on A as
> > +      * an ordinary fence; prove B' cannot complete before A.
> > +      */
> > +
> > +     ctx = gem_context_create(i915);
> > +
> > +     for (int class = 0; class < 32; class++) {
> > +             struct i915_engine_class_instance *siblings;
> > +             struct drm_i915_gem_execbuffer2 execbuf = {
> > +                     .buffers_ptr = to_user_pointer(&batch),
> > +                     .buffer_count = 1,
> > +                     .rsvd1 = ctx,
> > +             };
> > +             unsigned int count;
> > +             igt_spin_t *spin;
> > +
> > +             siblings = list_engines(i915, 1u << class, &count);
> > +             if (!siblings)
> > +                     continue;
> > +
> > +             if (count < 2) {
> > +                     free(siblings);
> > +                     continue;
> > +             }
> > +
> > +             /* A: spin forever on engine 1 */
> > +             set_load_balancer(i915, ctx, siblings, count, NULL);
> > +             spin = igt_spin_new(i915,
> > +                                 .ctx = ctx,
> > +                                 .engine = 1,
> > +                                 .flags = (IGT_SPIN_POLL_RUN |
> > +                                           IGT_SPIN_FENCE_OUT));
> > +             igt_spin_busywait_until_started(spin);
> > +
> > +             /* B: waits for A on engine 2 */
> > +             set_load_balancer(i915, ctx, siblings, count, NULL);
> > +             execbuf.rsvd2 = spin->out_fence;
> > +             execbuf.flags = I915_EXEC_FENCE_IN | I915_EXEC_FENCE_OUT;
> > +             execbuf.flags |= 2; /* opposite engine to spinner */
> 
> Why or?

execbuf.flags = 2 | FENCE_IN | FENCE_OUT

> 
> > +             gem_execbuf_wr(i915, &execbuf);
> > +
> > +             /* B': run in parallel with B on engine 1, i.e. not before A! */
> > +             set_load_balancer(i915, ctx, siblings, count, NULL);
> 
> Why are you repeating the same set_load_balancer calls?

Because we need a new timeline wrt the spinner.
(Well B' does. I originally tried using the virtual engine here, but
semaphores are not guaranteed so it works better by forcing the engine
selection to the known bad pattern.)

> > +             execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
> > +             execbuf.flags |= 1; /* same engine as spinner */
> 
> Engine 3? But there are only two engines in the map, plus the virtual. 
> So 0, 1, 2 - how does this work for you?

execbuf.flags = 1 | FENCE_SUBMIT | FENCE_OUT;

> > +             execbuf.rsvd2 >>= 32;
> > +             gem_execbuf_wr(i915, &execbuf);
> > +
> > +             /* Wait for any magic timeslicing or preemptions... */
> > +             igt_assert_eq(sync_fence_wait(execbuf.rsvd2 >> 32, 1000),
> > +                           -ETIME);
> > +
> > +             igt_debugfs_dump(i915, "i915_engine_info");
> > +
> > +             /*
> > +              * ... which should not have happened, so everything is still
> > +              * waiting on the spinner
> > +              */
> > +             igt_assert_eq(sync_fence_status(spin->out_fence), 0);
> > +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 0);
> > +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 0);
> > +
> > +             igt_spin_free(i915, spin);
> > +             gem_sync(i915, batch.handle);
> > +
> > +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 1);
> > +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
> > +
> > +             close(execbuf.rsvd2);
> > +             close(execbuf.rsvd2 >> 32);
> > +     }
> 
> How evil to lower ctx prio for A only?

A draw. You swap the timeslicing catch for the explicit preemption
check.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

* [igt-dev] ✗ GitLab.Pipeline: failure for i915/gem_exec_balance: Check chain of submit dependencies
  2019-11-27 14:50 [igt-dev] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies Chris Wilson
  2019-11-27 15:08 ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin
@ 2019-11-27 15:17 ` Patchwork
  2019-11-27 15:25 ` [igt-dev] ✗ Fi.CI.BAT: " Patchwork
  2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-11-27 15:17 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev

== Series Details ==

Series: i915/gem_exec_balance: Check chain of submit dependencies
URL   : https://patchwork.freedesktop.org/series/70117/
State : failure

== Summary ==

ERROR! This series introduces new undocumented tests:

gem_exec_balancer@bonded-chain

Can you document them as per the requirement in the [CONTRIBUTING.md]?

[Documentation] has more details on how to do this.

Here are few examples:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/0316695d03aa46108296b27f3982ec93200c7a6e
https://gitlab.freedesktop.org/drm/igt-gpu-tools/commit/443cc658e1e6b492ee17bf4f4d891029eb7a205d

Thanks in advance!

[CONTRIBUTING.md]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/CONTRIBUTING.md#L19
[Documentation]: https://drm.pages.freedesktop.org/igt-gpu-tools/igt-gpu-tools-Core.html#igt-describe

Other than that, pipeline status: SUCCESS.

see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/83320 for the overview.

== Logs ==

For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/pipelines/83320
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

* Re: [igt-dev] [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies
  2019-11-27 15:15   ` Chris Wilson
@ 2019-11-27 15:20     ` Tvrtko Ursulin
  0 siblings, 0 replies; 6+ messages in thread
From: Tvrtko Ursulin @ 2019-11-27 15:20 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx; +Cc: igt-dev


On 27/11/2019 15:15, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-11-27 15:08:25)
>>
>> On 27/11/2019 14:50, Chris Wilson wrote:
>>> Check that the submit fence couples into the dependency chain so that
>>> the bonded pair cannot over take any of the earlier requests.
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> ---
>>>    tests/i915/gem_exec_balancer.c | 88 ++++++++++++++++++++++++++++++++++
>>>    1 file changed, 88 insertions(+)
>>>
>>> diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
>>> index 86028cfdd..ff5bd0134 100644
>>> --- a/tests/i915/gem_exec_balancer.c
>>> +++ b/tests/i915/gem_exec_balancer.c
>>> @@ -855,6 +855,91 @@ static void bonded_slice(int i915)
>>>        munmap(stop, 4096);
>>>    }
>>>    
>>> +static void bonded_chain(int i915)
>>> +{
>>> +     struct drm_i915_gem_exec_object2 batch = {
>>> +             .handle = batch_create(i915),
>>> +     };
>>> +     uint32_t ctx;
>>> +
>>> +     /*
>>> +      * Given batches A, B and B', where B and B' are a bonded pair, with
>>> +      * B' depending on B with a submit fence and B depending on A as
>>> +      * an ordinary fence; prove B' cannot complete before A.
>>> +      */
>>> +
>>> +     ctx = gem_context_create(i915);
>>> +
>>> +     for (int class = 0; class < 32; class++) {
>>> +             struct i915_engine_class_instance *siblings;
>>> +             struct drm_i915_gem_execbuffer2 execbuf = {
>>> +                     .buffers_ptr = to_user_pointer(&batch),
>>> +                     .buffer_count = 1,
>>> +                     .rsvd1 = ctx,
>>> +             };
>>> +             unsigned int count;
>>> +             igt_spin_t *spin;
>>> +
>>> +             siblings = list_engines(i915, 1u << class, &count);
>>> +             if (!siblings)
>>> +                     continue;
>>> +
>>> +             if (count < 2) {
>>> +                     free(siblings);
>>> +                     continue;
>>> +             }
>>> +
>>> +             /* A: spin forever on engine 1 */
>>> +             set_load_balancer(i915, ctx, siblings, count, NULL);
>>> +             spin = igt_spin_new(i915,
>>> +                                 .ctx = ctx,
>>> +                                 .engine = 1,
>>> +                                 .flags = (IGT_SPIN_POLL_RUN |
>>> +                                           IGT_SPIN_FENCE_OUT));
>>> +             igt_spin_busywait_until_started(spin);
>>> +
>>> +             /* B: waits for A on engine 2 */
>>> +             set_load_balancer(i915, ctx, siblings, count, NULL);
>>> +             execbuf.rsvd2 = spin->out_fence;
>>> +             execbuf.flags = I915_EXEC_FENCE_IN | I915_EXEC_FENCE_OUT;
>>> +             execbuf.flags |= 2; /* opposite engine to spinner */
>>
>> Why or?
> 
> execbuf.flags = 2 | FENCE_IN | FENCE_OUT

/me facepalms

>>
>>> +             gem_execbuf_wr(i915, &execbuf);
>>> +
>>> +             /* B': run in parallel with B on engine 1, i.e. not before A! */
>>> +             set_load_balancer(i915, ctx, siblings, count, NULL);
>>
>> Why are you repeating the same set_load_balancer calls?
> 
> Because we need a new timeline wrt the spinner.
> (Well B' does. I originally tried using the virtual engine here, but
> semaphores are not guaranteed so it works better by forcing the engine
> selection to the known bad pattern.)

Yeah.. makes sense. Please drop a short comment to that effect and with 
that:

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko

>>> +             execbuf.flags = I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
>>> +             execbuf.flags |= 1; /* same engine as spinner */
>>
>> Engine 3? But there are only two engines in the map, plus the virtual.
>> So 0, 1, 2 - how does this work for you?
> 
> execbuf.flags = 1 | FENCE_SUBMIT | FENCE_OUT;
> 
>>> +             execbuf.rsvd2 >>= 32;
>>> +             gem_execbuf_wr(i915, &execbuf);
>>> +
>>> +             /* Wait for any magic timeslicing or preemptions... */
>>> +             igt_assert_eq(sync_fence_wait(execbuf.rsvd2 >> 32, 1000),
>>> +                           -ETIME);
>>> +
>>> +             igt_debugfs_dump(i915, "i915_engine_info");
>>> +
>>> +             /*
>>> +              * ... which should not have happened, so everything is still
>>> +              * waiting on the spinner
>>> +              */
>>> +             igt_assert_eq(sync_fence_status(spin->out_fence), 0);
>>> +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 0);
>>> +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 0);
>>> +
>>> +             igt_spin_free(i915, spin);
>>> +             gem_sync(i915, batch.handle);
>>> +
>>> +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 & 0xffffffff), 1);
>>> +             igt_assert_eq(sync_fence_status(execbuf.rsvd2 >> 32), 1);
>>> +
>>> +             close(execbuf.rsvd2);
>>> +             close(execbuf.rsvd2 >> 32);
>>> +     }
>>
>> How evil to lower ctx prio for A only?
> 
> A draw. You swap the timeslicing catch for the explicit preemption
> check.
> -Chris
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

* [igt-dev] ✗ Fi.CI.BAT: failure for i915/gem_exec_balance: Check chain of submit dependencies
  2019-11-27 14:50 [igt-dev] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies Chris Wilson
  2019-11-27 15:08 ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin
  2019-11-27 15:17 ` [igt-dev] ✗ GitLab.Pipeline: failure for " Patchwork
@ 2019-11-27 15:25 ` Patchwork
  2 siblings, 0 replies; 6+ messages in thread
From: Patchwork @ 2019-11-27 15:25 UTC (permalink / raw)
  To: Chris Wilson; +Cc: igt-dev

== Series Details ==

Series: i915/gem_exec_balance: Check chain of submit dependencies
URL   : https://patchwork.freedesktop.org/series/70117/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_7431 -> IGTPW_3769
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_3769 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_3769, 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_3769/index.html

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live_gt_pm:
    - fi-kbl-guc:         [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-kbl-guc/igt@i915_selftest@live_gt_pm.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-kbl-guc/igt@i915_selftest@live_gt_pm.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@i915_pm_rpm@module-reload:
    - fi-skl-6770hq:      [PASS][3] -> [FAIL][4] ([fdo#108511])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html

  * igt@i915_selftest@live_gem_contexts:
    - fi-skl-lmem:        [PASS][5] -> [DMESG-FAIL][6] ([fdo#112402])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html
    - fi-cfl-8700k:       [PASS][7] -> [INCOMPLETE][8] ([fdo#111700])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
    - fi-cfl-guc:         [PASS][9] -> [INCOMPLETE][10] ([fdo#106070] / [fdo#111700])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-icl-u2:          [PASS][11] -> [FAIL][12] ([fdo#103167])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-icl-u2/igt@kms_frontbuffer_tracking@basic.html

  
#### Warnings ####

  * igt@gem_exec_suspend@basic-s4-devices:
    - fi-kbl-x1275:       [DMESG-WARN][13] ([fdo#103558] / [fdo#105602] / [fdo#105763] / [fdo#107139]) -> [DMESG-WARN][14] ([fdo#103558] / [fdo#105602] / [fdo#107139])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-kbl-x1275/igt@gem_exec_suspend@basic-s4-devices.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-kbl-x1275/igt@gem_exec_suspend@basic-s4-devices.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-kbl-x1275:       [DMESG-WARN][15] ([fdo#103558] / [fdo#105602]) -> [DMESG-WARN][16] ([fdo#103558] / [fdo#105602] / [fdo#105763]) +4 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_flip@basic-flip-vs-modeset:
    - fi-kbl-x1275:       [DMESG-WARN][17] ([fdo#103558] / [fdo#105602] / [fdo#105763]) -> [DMESG-WARN][18] ([fdo#103558] / [fdo#105602]) +8 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7431/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
  [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
  [fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#107139]: https://bugs.freedesktop.org/show_bug.cgi?id=107139
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
  [fdo#112402]: https://bugs.freedesktop.org/show_bug.cgi?id=112402


Participating hosts (52 -> 45)
------------------------------

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


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5310 -> IGTPW_3769

  CI-20190529: 20190529
  CI_DRM_7431: 1e2339ed90d558c4bb1d154b0ea2a51e11da8196 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3769: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3769/index.html
  IGT_5310: d1ea62b3f759f10ff6860561ba82e5c4902511d3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_exec_balancer@bonded-chain

== Logs ==

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

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

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

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-27 14:50 [igt-dev] [PATCH i-g-t] i915/gem_exec_balance: Check chain of submit dependencies Chris Wilson
2019-11-27 15:08 ` [igt-dev] [Intel-gfx] " Tvrtko Ursulin
2019-11-27 15:15   ` Chris Wilson
2019-11-27 15:20     ` Tvrtko Ursulin
2019-11-27 15:17 ` [igt-dev] ✗ GitLab.Pipeline: failure for " Patchwork
2019-11-27 15:25 ` [igt-dev] ✗ Fi.CI.BAT: " Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox