From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Date: Fri, 31 Jul 2020 22:11:05 +0300 [thread overview]
Message-ID: <321c335c-35a4-381f-c9d1-42221d6cad41@intel.com> (raw)
In-Reply-To: <159620596470.21624.386540668077781122@build.alporthouse.com>
On 31/07/2020 17:32, Chris Wilson wrote:
> Quoting Lionel Landwerlin (2020-07-31 14:45:52)
>> Introduces a new parameters to execbuf so that we can specify syncobj
>> handles as well as timeline points.
>>
>> v2: Reuse i915_user_extension_fn
>>
>> v3: Check that the chained extension is only present once (Chris)
>>
>> v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
>>
>> v5: Use BIT_ULL (Chris)
>>
>> v6: Fix issue with already signaled timeline points,
>> dma_fence_chain_find_seqno() setting fence to NULL (Chris)
>>
>> v7: Report ENOENT with invalid syncobj handle (Lionel)
>>
>> v8: Check for out of order timeline point insertion (Chris)
>>
>> v9: After explanations on
>> https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
>> drop the ordering check from v8 (Lionel)
>>
>> v10: Set first extension enum item to 1 (Jason)
> The other unaddressed issue here is that we do not need to arbitrarily
> limit the caller to only a single extension. The code to handle multiple
> invocations is actually smaller...
> -Chris
You mean an application could send multiple
DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES items in the chain of
extensions?
That's somewhat different than how the current fences are handled.
If other extension want to support that, that's up to them.
We don't have any use for multiple arrays of timeline fences for a given
execbuf in our userspace driver.
-Lionel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-07-31 19:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-31 13:45 [Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support Lionel Landwerlin
2020-07-31 13:45 ` [Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2 Lionel Landwerlin
2020-07-31 13:45 ` [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support Lionel Landwerlin
2020-07-31 14:30 ` Chris Wilson
2020-07-31 19:06 ` Lionel Landwerlin
2020-08-01 9:21 ` Daniel Vetter
2020-07-31 14:32 ` Chris Wilson
2020-07-31 19:11 ` Lionel Landwerlin [this message]
2020-07-31 13:45 ` [Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences Lionel Landwerlin
2020-07-31 14:17 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: timeline semaphore support Patchwork
2020-07-31 14:18 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-07-31 14:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-07-31 19:58 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2020-08-03 14:01 [Intel-gfx] [PATCH 0/3] " Lionel Landwerlin
2020-08-03 14:01 ` [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support Lionel Landwerlin
2020-08-03 9:05 [Intel-gfx] [PATCH 0/3] drm/i915: timeline semaphore support Lionel Landwerlin
2020-08-03 9:05 ` [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support Lionel Landwerlin
2020-04-06 20:07 [Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2 Venkata Sandeep Dhanalakota
2020-04-06 20:07 ` [Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support Venkata Sandeep Dhanalakota
2020-04-08 16:29 ` Lionel Landwerlin
2020-04-08 17:00 ` Venkata Sandeep Dhanalakota
2020-04-08 17:14 ` Lionel Landwerlin
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=321c335c-35a4-381f-c9d1-42221d6cad41@intel.com \
--to=lionel.g.landwerlin@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@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 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.