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 v2 08/10] tests/i915/exec_fence: add timeline fence tests
Date: Fri, 22 Nov 2019 18:03:16 +0200 [thread overview]
Message-ID: <00eea48c-1e4f-446c-bc57-763c97c7ffd1@intel.com> (raw)
In-Reply-To: <157443789518.2524.2012790618955207394@skylake-alporthouse-com>
On 22/11/2019 17:51, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2019-11-22 15:43:11)
>> On 22/11/2019 17:26, Chris Wilson wrote:
>>> Quoting Lionel Landwerlin (2019-11-22 13:02:58)
>>>> We can now give a tuple (handle, point_value) for timeline semaphores.
>>>>
>>>> v2: Fix up syncobj-timeline-repeat test (Lionel)
>>>> Update following kernel rename
>>>>
>>>> v3: Add more ordering tests for syncobj/buffer handle state (Chris)
>>> Another question, do we worry about sw_sync imported fences being
>>> handles differently to native?
>>> -Chris
>> What do you mean by differently?
> We have is_i915_fence() with branching paths for internal/external, and
> within the syncobj timeline mixed fence contexts cause a hard barrier,
> so may present interesting effects at the uAPI layer?
Well... same issues with an array of i915 fences right?
I guess fence_set_priority() could be adjusted to deal with
dma-fence-chain like it does with dma-fence-array.
-Lionel
>
>> Thing is sw_sync can delay the signaling forever so you could build a
>> case exhausting memory if you really wanted.
> Except we don't allow indefinite waits for external fences such as
> sw_sync and wrap them in auto-expiring fences.
>
>> Whereas my understand of other dma-fences is that they should be short
>> lived.
> Endless. How's that going to end? Badly.
> -Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-11-22 16:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 13:02 [igt-dev] [PATCH i-g-t v2 00/10] tests: Add timeline syncobj testing Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 01/10] lib/syncobj: drop local declarations Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 02/10] drm-uapi: Update drm headers to 17cc51390c141662748dbbc2fe98f3ed10f2e13e Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 03/10] igt: add timeline test cases Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 04/10] tests/syncobj_timeline: add more timeline tests Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 05/10] tests/i915/exec_fence: switch to internal headers Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 06/10] tests/i915/exec_fence: reuse syncobj helpers Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 07/10] include: bump drm headers for i915 timeline semaphores Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 08/10] tests/i915/exec_fence: add timeline fence tests Lionel Landwerlin
2019-11-22 15:13 ` Chris Wilson
2019-11-22 15:17 ` Lionel Landwerlin
2019-11-22 15:23 ` Chris Wilson
2019-11-22 15:47 ` Lionel Landwerlin
2019-11-22 15:26 ` Chris Wilson
2019-11-22 15:43 ` Lionel Landwerlin
2019-11-22 15:51 ` Chris Wilson
2019-11-22 16:03 ` Lionel Landwerlin [this message]
2019-11-22 16:11 ` Chris Wilson
2019-11-27 16:04 ` Lionel Landwerlin
2019-11-22 13:02 ` [igt-dev] [PATCH i-g-t v2 09/10] lib/i915: Parse mmio base from debugfs Lionel Landwerlin
2019-11-22 13:03 ` [igt-dev] [PATCH i-g-t v2 10/10] tests/i915/gem_exec_fence: add engine chaining tests Lionel Landwerlin
2019-11-22 14:10 ` [igt-dev] ✗ GitLab.Pipeline: warning for tests: Add timeline syncobj testing (rev2) Patchwork
2019-11-22 14:16 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2019-11-23 21:15 ` [igt-dev] ✓ Fi.CI.IGT: " 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=00eea48c-1e4f-446c-bc57-763c97c7ffd1@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