From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: Intel-gfx@lists.freedesktop.org,
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t v2] tests/i915: Restore some BAT coverage
Date: Thu, 23 May 2019 15:02:30 +0300 [thread overview]
Message-ID: <87tvdl2xbd.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <155859468552.28319.675115669918159870@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Tvrtko Ursulin (2019-05-23 07:43:12)
>>
>> On 23/05/2019 07:37, Tvrtko Ursulin wrote:
>> > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> >
>> > Engine enumerated test names have changed so fast-feedback.testlist needs
>> > to be updated. However listing all engines there won't scale. So instead
>> > add new tests cases which iterate all engines internally.
>> >
>> > v2:
>> > * Fix basic-all test name.
>> > * Fix params to basic (bool false to zero).
>> > * Use I915_EXEC_DEFAULT in has_extended_busy_ioctl to workaround stateful
>> > contexts for now.
>> > * Have only basic-all in BAT. (Chris)
>> >
>> > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1
>> > Reviewed-by: Andi Shyti <andi.shyti@intel.com> # v1
>> > ---
>> > tests/i915/gem_busy.c | 19 +++++++++++----
>> > tests/i915/gem_exec_basic.c | 33 +++++++++++++++++++++++++++
>> > tests/intel-ci/fast-feedback.testlist | 31 ++-----------------------
>> > 3 files changed, 50 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/tests/i915/gem_busy.c b/tests/i915/gem_busy.c
>> > index 781a3bfab1d1..f3ebb37a33b4 100644
>> > --- a/tests/i915/gem_busy.c
>> > +++ b/tests/i915/gem_busy.c
>> > @@ -417,7 +417,7 @@ static bool has_semaphores(int fd)
>> >
>> > static bool has_extended_busy_ioctl(int fd)
>> > {
>> > - igt_spin_t *spin = igt_spin_new(fd, .engine = I915_EXEC_RENDER);
>> > + igt_spin_t *spin = igt_spin_new(fd, .engine = I915_EXEC_DEFAULT);
>>
>> (This fails on platforms with only rcs0 (no other engines) due context
>> has a map now, and I915_EXEC_RENDER == 1 == -EINVAL.)
>
> In which case, it probably should be a plain 0 as it no longer has the
> old EXEC_RING semantics but is just an index, i.e. igt_spin_new(fd);
>
>> We need to come up with a robust and easy to remember solution for
>> dealing with the fact contexts are stateful now and
>> __for_each_physical_engine iterator configures the default one.
>>
>> Could end game for test conversion be to stop passing in eb.flags to
>> igt_spin_new and do class:instance instead? That would enable dummyload
>> to unambiguously know what to use, depending on get_engines query.
>
> Speak to Mika, we abuse igt_spin_t much more by resubmitting the same
> dummyload to multiple engines and contexts.
I have wandered there yes. The reason for this abuse is still unclear.
We could do a clearer interface for creating spinners but is the
reusage due to latency concerns?
-Mika
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
WARNING: multiple messages have this Message-ID (diff)
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v2] tests/i915: Restore some BAT coverage
Date: Thu, 23 May 2019 15:02:30 +0300 [thread overview]
Message-ID: <87tvdl2xbd.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <155859468552.28319.675115669918159870@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Tvrtko Ursulin (2019-05-23 07:43:12)
>>
>> On 23/05/2019 07:37, Tvrtko Ursulin wrote:
>> > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> >
>> > Engine enumerated test names have changed so fast-feedback.testlist needs
>> > to be updated. However listing all engines there won't scale. So instead
>> > add new tests cases which iterate all engines internally.
>> >
>> > v2:
>> > * Fix basic-all test name.
>> > * Fix params to basic (bool false to zero).
>> > * Use I915_EXEC_DEFAULT in has_extended_busy_ioctl to workaround stateful
>> > contexts for now.
>> > * Have only basic-all in BAT. (Chris)
>> >
>> > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1
>> > Reviewed-by: Andi Shyti <andi.shyti@intel.com> # v1
>> > ---
>> > tests/i915/gem_busy.c | 19 +++++++++++----
>> > tests/i915/gem_exec_basic.c | 33 +++++++++++++++++++++++++++
>> > tests/intel-ci/fast-feedback.testlist | 31 ++-----------------------
>> > 3 files changed, 50 insertions(+), 33 deletions(-)
>> >
>> > diff --git a/tests/i915/gem_busy.c b/tests/i915/gem_busy.c
>> > index 781a3bfab1d1..f3ebb37a33b4 100644
>> > --- a/tests/i915/gem_busy.c
>> > +++ b/tests/i915/gem_busy.c
>> > @@ -417,7 +417,7 @@ static bool has_semaphores(int fd)
>> >
>> > static bool has_extended_busy_ioctl(int fd)
>> > {
>> > - igt_spin_t *spin = igt_spin_new(fd, .engine = I915_EXEC_RENDER);
>> > + igt_spin_t *spin = igt_spin_new(fd, .engine = I915_EXEC_DEFAULT);
>>
>> (This fails on platforms with only rcs0 (no other engines) due context
>> has a map now, and I915_EXEC_RENDER == 1 == -EINVAL.)
>
> In which case, it probably should be a plain 0 as it no longer has the
> old EXEC_RING semantics but is just an index, i.e. igt_spin_new(fd);
>
>> We need to come up with a robust and easy to remember solution for
>> dealing with the fact contexts are stateful now and
>> __for_each_physical_engine iterator configures the default one.
>>
>> Could end game for test conversion be to stop passing in eb.flags to
>> igt_spin_new and do class:instance instead? That would enable dummyload
>> to unambiguously know what to use, depending on get_engines query.
>
> Speak to Mika, we abuse igt_spin_t much more by resubmitting the same
> dummyload to multiple engines and contexts.
I have wandered there yes. The reason for this abuse is still unclear.
We could do a clearer interface for creating spinners but is the
reusage due to latency concerns?
-Mika
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-05-23 12:02 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 16:31 [igt-dev] [PATCH i-g-t] tests/i915: Restore some BAT coverage Tvrtko Ursulin
2019-05-22 16:31 ` Tvrtko Ursulin
2019-05-22 16:45 ` [igt-dev] " Chris Wilson
2019-05-22 16:45 ` Chris Wilson
2019-05-22 18:48 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-05-22 21:28 ` [igt-dev] [PATCH i-g-t] " Andi Shyti
2019-05-22 21:28 ` Andi Shyti
2019-05-23 6:37 ` [igt-dev] [PATCH i-g-t v2] " Tvrtko Ursulin
2019-05-23 6:37 ` Tvrtko Ursulin
2019-05-23 6:43 ` [igt-dev] " Tvrtko Ursulin
2019-05-23 6:43 ` Tvrtko Ursulin
2019-05-23 6:58 ` Chris Wilson
2019-05-23 6:58 ` Chris Wilson
2019-05-23 12:02 ` Mika Kuoppala [this message]
2019-05-23 12:02 ` Mika Kuoppala
2019-05-23 12:08 ` Chris Wilson
2019-05-23 12:08 ` Chris Wilson
2019-05-23 11:43 ` [Intel-gfx] " Chris Wilson
2019-05-23 11:43 ` Chris Wilson
2019-05-23 7:30 ` [igt-dev] ✗ Fi.CI.BAT: failure for tests/i915: Restore some BAT coverage (rev2) Patchwork
2019-05-23 11:00 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/i915: Restore some BAT coverage (rev3) Patchwork
2019-05-23 14:27 ` [igt-dev] ✓ Fi.CI.IGT: success for tests/i915: Restore some BAT coverage Patchwork
2019-05-24 9:11 ` [igt-dev] ✓ Fi.CI.IGT: success for tests/i915: Restore some BAT coverage (rev3) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvdl2xbd.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=igt-dev@lists.freedesktop.org \
--cc=tvrtko.ursulin@intel.com \
--cc=tvrtko.ursulin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.