* [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