public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 10/10] tests/i915/exec_fence: add timeline fence tests
Date: Fri, 2 Aug 2019 12:03:59 +0300	[thread overview]
Message-ID: <7a6d81bf-1bd1-9118-4fc6-7b0903f6d5c7@intel.com> (raw)
In-Reply-To: <156460522446.2512.13711873169438917838@skylake-alporthouse-com>

On 31/07/2019 23:33, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-07-25 11:30:34)
>> +static void test_syncobj_timeline_wait(int fd)
>> +{
>> +       const uint32_t bbe = MI_BATCH_BUFFER_END;
>> +       struct drm_i915_gem_exec_object2 obj;
>> +       struct drm_i915_gem_execbuffer2 execbuf;
>> +       struct drm_i915_gem_execbuffer_ext_timeline_fences timeline_fences;
>> +       struct drm_i915_gem_exec_fence fence = {
>> +               .handle = syncobj_create(fd, 0),
>> +       };
>> +       uint64_t value = 1;
>> +       igt_spin_t *spin;
>> +       unsigned engine;
>> +       unsigned handle[16];
>> +       int n;
>> +
>> +       /* Check that we can use the syncobj to asynchronous wait prior to
>> +        * execution.
>> +        */
>> +
>> +       gem_quiescent_gpu(fd);
>> +
>> +       spin = igt_spin_new(fd);
>> +
>> +       memset(&timeline_fences, 0, sizeof(timeline_fences));
>> +       timeline_fences.base.name = DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES;
>> +       timeline_fences.fence_count = 1;
>> +       timeline_fences.handles_ptr = to_user_pointer(&fence);
>> +       timeline_fences.values_ptr = to_user_pointer(&value);
>> +
>> +       memset(&execbuf, 0, sizeof(execbuf));
>> +       execbuf.buffers_ptr = to_user_pointer(&obj);
>> +       execbuf.buffer_count = 1;
>> +
>> +       memset(&obj, 0, sizeof(obj));
>> +       obj.handle = gem_create(fd, 4096);
>> +       gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
>> +
>> +       /* Queue a signaler from the blocked engine */
>> +       execbuf.flags = I915_EXEC_EXT;
>> +       execbuf.cliprects_ptr = to_user_pointer(&timeline_fences);
>> +       execbuf.num_cliprects = 0;
>> +       fence.flags = I915_EXEC_FENCE_SIGNAL;
>> +       gem_execbuf(fd, &execbuf);
>> +       igt_assert(gem_bo_busy(fd, spin->handle));
>> +
>> +       gem_close(fd, obj.handle);
>> +       obj.handle = gem_create(fd, 4096);
>> +       gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
> This handle is leaked. Instead of recreating a handle every time, you
> could export a sync-file.
>
>> +       n = 0;
>> +       for_each_engine(fd, engine) {
>> +               obj.handle = gem_create(fd, 4096);
>> +               gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
>> +
>> +               /* No inter-engine synchronisation, will complete */
>> +               if (engine == I915_EXEC_BLT) {
>> +                       execbuf.flags = engine;
>> +                       execbuf.cliprects_ptr = 0;
>> +                       execbuf.num_cliprects = 0;
>> +                       gem_execbuf(fd, &execbuf);
>> +                       gem_sync(fd, obj.handle);
>> +                       igt_assert(gem_bo_busy(fd, spin->handle));
>> +               }
>> +               igt_assert(gem_bo_busy(fd, spin->handle));
>> +
>> +               /* Now wait upon the blocked engine */
>> +               execbuf.flags = I915_EXEC_EXT | engine;
>> +               execbuf.cliprects_ptr = to_user_pointer(&timeline_fences);
>> +               execbuf.num_cliprects = 0;
>> +               fence.flags = I915_EXEC_FENCE_WAIT;
>> +               gem_execbuf(fd, &execbuf);
>> +
>> +               igt_assert(gem_bo_busy(fd, obj.handle));
>> +               handle[n++] = obj.handle;
>> +       }
> You could move this to a second context and avoid the differentiation
> between engines:
>
> 	fence.flags = I915_EXEC_FENCE_WAIT;
> 	execbuf.rsvd1 = gem_context_create(fd);
>
> 	n = 0;
> 	for_each_engine(fd, engine) {
> 		obj.handle = gem_create(fd, 4096);
> 		gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
>
> 		/* Unsynchronised will execute ahead of the blockage */
> 		execbuf.flags = engine;
> 		execbuf.cliprects_ptr = 0;
> 		gem_execbuf(fd, &execbuf);
> 		gem_sync(fd, obj.handle);


Not quite sure this ends up blocking on engine=1.


>
> 		/* Now wait upon the blocked engine */
> 		execbuf.flags |= I915_EXEC_EXT;
> 		execbuf.cliprects_ptr = to_user_pointer(&timeline_fences);
> 		gem_execbuf(fd, &execbuf);
> 		handle[n++] = obj.handle;
> 	}
> 	igt_assert(gem_bo_busy(fd, spin->handle));
> 	gem_context_destroy(fd, execbuf.rsvd1);
>
>> +       syncobj_destroy(fd, fence.handle);
>> +
>> +       for (int i = 0; i < n; i++)
>> +               igt_assert(gem_bo_busy(fd, handle[i]));
>> +
>> +       igt_spin_free(fd, spin);
>> +
>> +       for (int i = 0; i < n; i++) {
>> +               gem_sync(fd, handle[i]);
>> +               gem_close(fd, handle[i]);
>> +       }
>> +}


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

  reply	other threads:[~2019-08-02  9:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 10:30 [igt-dev] [PATCH i-g-t 00/10] Vulkan performance queries support & others Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 01/10] include: temporary import of headers Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 02/10] tests/i915-query: add new tests for perf configurations queries Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 03/10] tests/perf: add tests for holding preemption Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 04/10] tests/perf: add tests to new OA reconfiguration execbuf extension Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 05/10] lib/syncobj: drop local declarations Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 06/10] igt: add timeline test cases Lionel Landwerlin
2019-07-26  2:56   ` zhoucm1
2019-07-26  9:07     ` Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 07/10] tests/syncobj_timeline: add more timeline tests Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 08/10] tests/i915/exec_fence: switch to internal headers Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 09/10] tests/i915/exec_fence: reuse syncobj helpers Lionel Landwerlin
2019-07-25 10:30 ` [igt-dev] [PATCH i-g-t 10/10] tests/i915/exec_fence: add timeline fence tests Lionel Landwerlin
2019-07-31 20:33   ` Chris Wilson
2019-08-02  9:03     ` Lionel Landwerlin [this message]
2019-08-02  9:11       ` Chris Wilson
2019-08-02  9:47         ` Lionel Landwerlin
2019-07-31 20:35   ` Chris Wilson
2019-07-25 11:18 ` [igt-dev] ✗ GitLab.Pipeline: warning for Vulkan performance queries support & others Patchwork
2019-07-25 11:19 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2019-07-25 16:37 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=7a6d81bf-1bd1-9118-4fc6-7b0903f6d5c7@intel.com \
    --to=lionel.g.landwerlin@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