Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Argenziano <antonio.argenziano@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] lib/hang_ctx: Make use of dummyload library to create recursive batch
Date: Mon, 9 Jul 2018 13:20:00 -0700	[thread overview]
Message-ID: <fb5e358c-b4e7-70d6-5e89-6131bef6610e@intel.com> (raw)
In-Reply-To: <153116598946.18500.4274248799278810480@skylake-alporthouse-com>



On 09/07/18 12:53, Chris Wilson wrote:
> Quoting Antonio Argenziano (2018-07-09 19:47:04)
>> An hanging batch is nothing more than a spinning batch that never gets
>> stopped, so re-use the routines implemented in dummyload.c.
>>
>> Signed-off-by: Antonio Argenziano <antonio.argenziano@intel.com>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> ---
>>   lib/igt_gt.c | 57 ++++++++-------------------------------------------------
>>   lib/igt_gt.h |  1 +
>>   2 files changed, 9 insertions(+), 49 deletions(-)
>>
>> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
>> index 4569fd36..25b7f1c4 100644
>> --- a/lib/igt_gt.c
>> +++ b/lib/igt_gt.c
>> @@ -264,14 +264,10 @@ igt_hang_t igt_hang_ctx(int fd,
>>                          unsigned flags,
>>                          uint64_t *offset)
>>   {
>> -       struct drm_i915_gem_relocation_entry reloc;
>> -       struct drm_i915_gem_execbuffer2 execbuf;
>> -       struct drm_i915_gem_exec_object2 exec;
>> +       igt_spin_t *spinning_batch;
>> +       struct igt_spin_factory opts = {};
>>          struct drm_i915_gem_context_param param;
>> -       uint32_t b[16];
>>          unsigned ban;
>> -       unsigned len;
>> -       int gen;
>>   
>>          igt_require_hang_ring(fd, ring);
>>   
>> @@ -295,52 +291,15 @@ igt_hang_t igt_hang_ctx(int fd,
>>          if ((flags & HANG_ALLOW_BAN) == 0)
>>                  context_set_ban(fd, ctx, 0);
>>   
>> -       memset(&reloc, 0, sizeof(reloc));
>> -       memset(&exec, 0, sizeof(exec));
>> -       memset(&execbuf, 0, sizeof(execbuf));
>> -
>> -       exec.handle = gem_create(fd, 4096);
>> -       exec.relocation_count = 1;
>> -       exec.relocs_ptr = to_user_pointer(&reloc);
>> -
>> -       memset(b, 0xc5, sizeof(b));
>> -
>> -       len = 0;
>> -       gen = intel_gen(intel_get_drm_devid(fd));
>> -       if (gen >= 8) {
>> -               b[len++] = MI_BATCH_BUFFER_START | 1 << 8 | 1;
>> -               b[len++] = 0;
>> -               b[len++] = 0;
>> -       } else if (gen >= 6) {
>> -               b[len++] = MI_BATCH_BUFFER_START | 1 << 8;
>> -               b[len++] = 0;
>> -       } else {
>> -               b[len++] = MI_BATCH_BUFFER_START | 2 << 6;
>> -               b[len] = 0;
>> -               if (gen < 4) {
>> -                       b[len] |= 1;
>> -                       reloc.delta = 1;
>> -               }
>> -               len++;
>> -       }
>> -       b[len++] = MI_BATCH_BUFFER_END;
>> -       b[len] = MI_NOOP;
>> -       gem_write(fd, exec.handle, 0, b, sizeof(b));
>> -
>> -       reloc.offset = sizeof(uint32_t);
>> -       reloc.target_handle = exec.handle;
>> -       reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
>> -
>> -       execbuf.buffers_ptr = to_user_pointer(&exec);
>> -       execbuf.buffer_count = 1;
>> -       execbuf.flags = ring;
>> -       i915_execbuffer2_set_context_id(execbuf, ctx);
>> -       gem_execbuf(fd, &execbuf);
>> +       opts.ctx = ctx;
>> +       opts.engine = ring;
>> +       opts.flags = IGT_SPIN_FAST; /* Current driver hangs faster */
> 
> Be careful, the hanging batch is where we first encountered the
> traumatic experience from spinning too fast. Use IGT_SPIN_FAST with
> care, and probably best left to the caller's discretion.

I'll leave it to the caller to spin faster. I actually wanted to add 
both hanging batches: fast and slow. My idea would be to have, even if 
only basics, hang tests for all situations: Moving Head; Still HEAD; 
Idle engine are the ones that come to mind. We could have a require() 
for gen version if needed.

Thanks,
Antonio

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

  reply	other threads:[~2018-07-09 20:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 18:47 [igt-dev] [PATCH i-g-t] lib/hang_ctx: Make use of dummyload library to create recursive batch Antonio Argenziano
2018-07-09 19:12 ` [igt-dev] ✗ Fi.CI.BAT: failure for " Patchwork
2018-07-09 19:53 ` [igt-dev] [PATCH i-g-t] " Chris Wilson
2018-07-09 20:20   ` Antonio Argenziano [this message]
2018-07-09 20:36     ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2018-07-13  8:14 [Intel-gfx] " Chris Wilson
2018-07-13  9:26 ` [igt-dev] " Chris Wilson

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=fb5e358c-b4e7-70d6-5e89-6131bef6610e@intel.com \
    --to=antonio.argenziano@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox