From: Daniel Vetter <daniel@ffwll.ch> To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>, Jason Ekstrand <jason@jlekstrand.net> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API Date: Mon, 22 Mar 2021 15:57:27 +0100 [thread overview] Message-ID: <CAKMK7uG0GLPu+auqDgMgD7ugvWo3E7W7DL6eALKxmp6hk-aZiA@mail.gmail.com> (raw) In-Reply-To: <d83162e2-4b9e-c7e9-5324-6612bb9561d6@linux.intel.com> On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote: > > > On 22/03/2021 14:09, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 11:22:01AM +0000, Tvrtko Ursulin wrote: > >> > >> On 19/03/2021 22:38, Jason Ekstrand wrote: > >>> This API allows one context to grab bits out of another context upon > >>> creation. It can be used as a short-cut for setparam(getparam()) for > >>> things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > >>> real userspace. It's used by a few IGT tests and that's it. Since it > >>> doesn't add any real value (most of the stuff you can CLONE you can copy > >>> in other ways), drop it. > >> > >> No complaints to remove if it ended up unused outside IGT. Latter is a _big_ > >> problem though, since it is much more that a few IGT tests. So I really > >> think there really needs to be an evaluation and a plan for that (we don't > >> want to lose 50% of the coverage over night). > >> > >>> There is one thing that this API allows you to clone which you cannot > >>> clone via getparam/setparam: timelines. However, timelines are an > >>> implementation detail of i915 and not really something that needs to be > >> > >> Not really true timelines are i915 implementation detail. They are in fact a > >> dma-fence context:seqno concept, nothing more that than. I think you are > >> probably confusing struct intel_timeline with the timeline wording in the > >> uapi. Former is i915 implementation detail, but context:seqno are truly > >> userspace timelines. > > > > I think you're both saying the same thing and talking a bit past each > > another. > > > > Yes the timeline is just a string of dma_fence, that's correct. Now > > usually if you submit batches with execbuf, we have 3 ways to synchronize > > concurrent submission: implicit sync, sync_file and drm_syncob. They all > > map to different needs in different protocols/render apis. > > > > Now in one additional case the kernel makes sure that batchbuffers are > > ordered, and that's when you submit them to the same hw ctx. Because > > there's only 1 hw context and you really can't have batchbuffers run on > > that single hw context out of order. That's what the timeline object we > > talk about here is. But that largely is an internal implementation detail, > > which happens to also use most/all the same infrastructure as the > > dma_fence uapi pieces above. > > > > Now the internal implementation detail leaking here is that we exposed > > this to userspace, without there being any need for this. What Jason > > implements with syncobj in the next patch is essentially what userspace > > should have been using for cross-engine sync. media userspace doesn't care > > about interop with winsys/client apis, so they equally could have used > > implicit sync or sync_file here (which I think is the solution now for the > > new uapi prepped internally), since they all are about equally powerful > > for stringing batchbuffers together. > > Are you saying we exposed a single timeline of execution per hw context > via the single timeline flag?! Nope. > Timelines of execution were always exposed. Any "engine" (ring > previously) in I915_EXEC_RING_MASK was a single timeline of execution. > It is completely the same with engine map engines, which are also > different indices into I915_EXEC_RING_MASK space. > > Userspace was aware of these timelines forever as well. Media was > creating multiple contexts to have multiple timelines (so parallelism). > Everyone knew that engine-hopping submissions needs to be either > implicitly or explicitly synchronised, etc. Yup, I think we're saying the same thing here. > So I really don't see that we have leaked timelines as a concept *now*. > What the patch has exposed to userspace is a new way to sync between > timelines and nothing more. We've leaked it as something you can now share across hw context. Which is possible because of how it's internally implemented (I think load balancer relies on that), but not really a synchronization primitive we want to export as such to userspace. We have other interfaces and concepts for that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org> Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API Date: Mon, 22 Mar 2021 15:57:27 +0100 [thread overview] Message-ID: <CAKMK7uG0GLPu+auqDgMgD7ugvWo3E7W7DL6eALKxmp6hk-aZiA@mail.gmail.com> (raw) In-Reply-To: <d83162e2-4b9e-c7e9-5324-6612bb9561d6@linux.intel.com> On Mon, Mar 22, 2021 at 3:33 PM Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote: > > > On 22/03/2021 14:09, Daniel Vetter wrote: > > On Mon, Mar 22, 2021 at 11:22:01AM +0000, Tvrtko Ursulin wrote: > >> > >> On 19/03/2021 22:38, Jason Ekstrand wrote: > >>> This API allows one context to grab bits out of another context upon > >>> creation. It can be used as a short-cut for setparam(getparam()) for > >>> things like I915_CONTEXT_PARAM_VM. However, it's never been used by any > >>> real userspace. It's used by a few IGT tests and that's it. Since it > >>> doesn't add any real value (most of the stuff you can CLONE you can copy > >>> in other ways), drop it. > >> > >> No complaints to remove if it ended up unused outside IGT. Latter is a _big_ > >> problem though, since it is much more that a few IGT tests. So I really > >> think there really needs to be an evaluation and a plan for that (we don't > >> want to lose 50% of the coverage over night). > >> > >>> There is one thing that this API allows you to clone which you cannot > >>> clone via getparam/setparam: timelines. However, timelines are an > >>> implementation detail of i915 and not really something that needs to be > >> > >> Not really true timelines are i915 implementation detail. They are in fact a > >> dma-fence context:seqno concept, nothing more that than. I think you are > >> probably confusing struct intel_timeline with the timeline wording in the > >> uapi. Former is i915 implementation detail, but context:seqno are truly > >> userspace timelines. > > > > I think you're both saying the same thing and talking a bit past each > > another. > > > > Yes the timeline is just a string of dma_fence, that's correct. Now > > usually if you submit batches with execbuf, we have 3 ways to synchronize > > concurrent submission: implicit sync, sync_file and drm_syncob. They all > > map to different needs in different protocols/render apis. > > > > Now in one additional case the kernel makes sure that batchbuffers are > > ordered, and that's when you submit them to the same hw ctx. Because > > there's only 1 hw context and you really can't have batchbuffers run on > > that single hw context out of order. That's what the timeline object we > > talk about here is. But that largely is an internal implementation detail, > > which happens to also use most/all the same infrastructure as the > > dma_fence uapi pieces above. > > > > Now the internal implementation detail leaking here is that we exposed > > this to userspace, without there being any need for this. What Jason > > implements with syncobj in the next patch is essentially what userspace > > should have been using for cross-engine sync. media userspace doesn't care > > about interop with winsys/client apis, so they equally could have used > > implicit sync or sync_file here (which I think is the solution now for the > > new uapi prepped internally), since they all are about equally powerful > > for stringing batchbuffers together. > > Are you saying we exposed a single timeline of execution per hw context > via the single timeline flag?! Nope. > Timelines of execution were always exposed. Any "engine" (ring > previously) in I915_EXEC_RING_MASK was a single timeline of execution. > It is completely the same with engine map engines, which are also > different indices into I915_EXEC_RING_MASK space. > > Userspace was aware of these timelines forever as well. Media was > creating multiple contexts to have multiple timelines (so parallelism). > Everyone knew that engine-hopping submissions needs to be either > implicitly or explicitly synchronised, etc. Yup, I think we're saying the same thing here. > So I really don't see that we have leaked timelines as a concept *now*. > What the patch has exposed to userspace is a new way to sync between > timelines and nothing more. We've leaked it as something you can now share across hw context. Which is possible because of how it's internally implemented (I think load balancer relies on that), but not really a synchronization primitive we want to export as such to userspace. We have other interfaces and concepts for that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-03-22 14:57 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-19 22:38 [PATCH 0/4] drm/i915: uAPI clean-ups part 2 Jason Ekstrand 2021-03-19 22:38 ` [Intel-gfx] " Jason Ekstrand 2021-03-19 22:38 ` [PATCH 1/4] drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE Jason Ekstrand 2021-03-19 22:38 ` [Intel-gfx] " Jason Ekstrand 2021-03-20 14:48 ` Jason Ekstrand 2021-03-20 14:48 ` [Intel-gfx] " Jason Ekstrand 2021-03-22 10:52 ` Matthew Auld 2021-03-22 10:52 ` Matthew Auld 2021-03-22 16:00 ` Jason Ekstrand 2021-03-22 16:00 ` Jason Ekstrand 2021-03-22 12:01 ` Jani Nikula 2021-03-22 12:01 ` Jani Nikula 2021-03-22 16:01 ` Jason Ekstrand 2021-03-22 16:01 ` Jason Ekstrand 2021-03-22 16:26 ` Daniel Vetter 2021-03-22 16:26 ` Daniel Vetter 2021-03-19 22:38 ` [PATCH 2/4] drm/i915: Drop I915_CONTEXT_PARAM_NO_ZEROMAP Jason Ekstrand 2021-03-19 22:38 ` [Intel-gfx] " Jason Ekstrand 2021-03-22 13:00 ` [drm/i915] 014c1518e8: assertion_failure kernel test robot 2021-03-22 13:00 ` kernel test robot 2021-03-22 13:00 ` [Intel-gfx] " kernel test robot 2021-03-22 13:00 ` kernel test robot 2021-03-19 22:38 ` [PATCH 3/4] drm/i915: Drop the CONTEXT_CLONE API Jason Ekstrand 2021-03-19 22:38 ` [Intel-gfx] " Jason Ekstrand 2021-03-22 11:22 ` Tvrtko Ursulin 2021-03-22 11:22 ` Tvrtko Ursulin 2021-03-22 14:09 ` Daniel Vetter 2021-03-22 14:09 ` Daniel Vetter 2021-03-22 14:32 ` Tvrtko Ursulin 2021-03-22 14:32 ` Tvrtko Ursulin 2021-03-22 14:57 ` Daniel Vetter [this message] 2021-03-22 14:57 ` Daniel Vetter 2021-03-22 15:31 ` Tvrtko Ursulin 2021-03-22 15:31 ` Tvrtko Ursulin 2021-03-22 16:24 ` Jason Ekstrand 2021-03-22 16:24 ` Jason Ekstrand 2021-03-23 9:46 ` Tvrtko Ursulin 2021-03-23 9:46 ` Tvrtko Ursulin 2021-03-22 16:43 ` Daniel Vetter 2021-03-22 16:43 ` Daniel Vetter 2021-03-23 9:14 ` Tvrtko Ursulin 2021-03-23 9:14 ` Tvrtko Ursulin 2021-03-23 13:23 ` Daniel Vetter 2021-03-23 13:23 ` Daniel Vetter 2021-03-23 16:23 ` Tvrtko Ursulin 2021-03-23 16:23 ` Tvrtko Ursulin 2021-03-23 17:50 ` Jason Ekstrand 2021-03-23 17:50 ` Jason Ekstrand 2021-03-19 22:38 ` [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj Jason Ekstrand 2021-03-19 22:38 ` [Intel-gfx] " Jason Ekstrand 2021-03-22 12:28 ` Tvrtko Ursulin 2021-03-22 12:28 ` Tvrtko Ursulin 2021-03-22 16:10 ` Jason Ekstrand 2021-03-22 16:10 ` Jason Ekstrand 2021-03-23 9:35 ` Tvrtko Ursulin 2021-03-23 9:35 ` Tvrtko Ursulin 2021-03-23 17:44 ` Jason Ekstrand 2021-03-23 17:44 ` Jason Ekstrand 2021-03-22 16:59 ` Daniel Vetter 2021-03-22 16:59 ` Daniel Vetter 2021-03-22 19:12 ` Jason Ekstrand 2021-03-22 19:12 ` Jason Ekstrand 2021-03-23 17:51 ` [PATCH] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v2) Jason Ekstrand 2021-03-23 17:51 ` [Intel-gfx] " Jason Ekstrand 2021-03-24 9:28 ` Tvrtko Ursulin 2021-03-24 9:28 ` Tvrtko Ursulin 2021-03-24 9:52 ` Daniel Vetter 2021-03-24 9:52 ` Daniel Vetter 2021-03-24 11:36 ` Tvrtko Ursulin 2021-03-24 11:36 ` Tvrtko Ursulin 2021-03-24 17:18 ` Jason Ekstrand 2021-03-24 17:18 ` Jason Ekstrand 2021-03-25 9:48 ` Tvrtko Ursulin 2021-03-25 9:48 ` Tvrtko Ursulin 2021-03-25 9:54 ` Daniel Vetter 2021-03-25 9:54 ` Daniel Vetter 2021-03-24 9:46 ` Daniel Vetter 2021-03-24 9:46 ` Daniel Vetter 2021-03-25 21:13 ` Matthew Brost 2021-03-25 21:13 ` [Intel-gfx] " Matthew Brost 2021-03-25 22:19 ` Jason Ekstrand 2021-03-25 22:19 ` [Intel-gfx] " Jason Ekstrand 2021-03-25 22:21 ` [PATCH 4/4] drm/i915: Implement SINGLE_TIMELINE with a syncobj (v3) Jason Ekstrand 2021-03-25 22:21 ` [Intel-gfx] " Jason Ekstrand 2021-03-19 23:14 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2 Patchwork 2021-03-22 11:55 ` Jani Nikula 2021-03-22 16:11 ` Jason Ekstrand 2021-03-23 21:32 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2 (rev2) Patchwork 2021-03-26 3:01 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: uAPI clean-ups part 2 (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=CAKMK7uG0GLPu+auqDgMgD7ugvWo3E7W7DL6eALKxmp6hk-aZiA@mail.gmail.com \ --to=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=jason@jlekstrand.net \ --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: linkBe 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.