From: Daniel Vetter <daniel@ffwll.ch> To: "Christian König" <christian.koenig@amd.com> Cc: Dave Airlie <airlied@gmail.com>, Maarten Lankhorst <maarten.lankhorst@canonical.com>, Thomas Hellstrom <thellstrom@vmware.com>, nouveau <nouveau@lists.freedesktop.org>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com>, "Deucher, Alexander" <alexander.deucher@amd.com> Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Tue, 22 Jul 2014 13:46:07 +0200 [thread overview] Message-ID: <20140722114607.GL15237@phenom.ffwll.local> (raw) In-Reply-To: <53CE2421.5040906@amd.com> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote: > Am 22.07.2014 06:05, schrieb Dave Airlie: > >On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst@canonical.com> wrote: > >>Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > >>--- > >> drivers/gpu/drm/radeon/radeon.h | 15 +- > >> drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++- > >> drivers/gpu/drm/radeon/radeon_fence.c | 223 ++++++++++++++++++++++++++------ > >> 3 files changed, 248 insertions(+), 50 deletions(-) > >> > > From what I can see this is still suffering from the problem that we > >need to find a proper solution to, > > > >My summary of the issues after talking to Jerome and Ben and > >re-reading things is: > > > >We really need to work out a better interface into the drivers to be > >able to avoid random atomic entrypoints, > > Which is exactly what I criticized from the very first beginning. Good to > know that I'm not the only one thinking that this isn't such a good idea. I guess I've lost context a bit, but which atomic entry point are we talking about? Afaics the only one that's mandatory is the is fence->signaled callback to check whether a fence really has been signalled. It's used internally by the fence code to avoid spurious wakeups. Afaik that should be doable already on any hardware. If that's not the case then we can always track the signalled state in software and double-check in a worker thread before updating the sw state. And wrap this all up into a special fence class if there's more than one driver needing this. There is nothing else that forces callbacks from atomic contexts upon you. You can use them if you see it fit, but really if it doesn't suit your driver you can just ignore that part and do process based waits everywhere. > >I'm sure you have some ideas and I think you really need to > >investigate them to move this thing forward, > >even it if means some issues with android sync pts. > > Actually I think that TTMs fence interface already gave quite a good hint > how it might look like. I can only guess that this won't fit with the > Android stuff, otherwise I can't see a good reason why we didn't stick with > that. Well the current plan for i915<->radeon sync from Maarten is to use these atomic callbacks on the i915 side. So android didn't figure into this at all. Actually with android the entire implementation is kinda the platforms problem, the generic parts just give you a userspace interface and some means to stack up fences. > >but none of the two major drivers seem to want the interface as-is so > >something needs to give > > > >My major question is why we need an atomic callback here at all, what > >scenario does it cover? > > Agree totally. As far as I can see all current uses of the interface are of > the kind of waiting for a fence to signal. > > No need for any callback from one driver into another, especially not in > atomic context. If a driver needs such a functionality it should just start > up a kernel thread and do it's waiting there. > > This obviously shouldn't be an obstacle for pure hardware implementations > where one driver signals a semaphore another driver is waiting for, or a > high signal on an interrupt line directly wired between two chips. And I > think this is a completely different topic and not necessarily part of the > common fence interface we should currently focus on. It's for mixed hw/sw stuff where we want to poke the hw from the irq context (if possible) since someone forgot the wire. At least on the i915 side it boils down to one mmio write, and it's fairly pointless to launch a thread for that. So I haven't dug into ttm details but from the i915 side the current stuff and atomic semantics makes sense. Maybe we just need to wrap a bit more insulation around ttm-based drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> To: "Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org> Cc: Thomas Hellstrom <thellstrom-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>, nouveau <nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, dri-devel <dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, "Deucher, Alexander" <alexander.deucher-5C7GfCeVMHo@public.gmane.org>, Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Tue, 22 Jul 2014 13:46:07 +0200 [thread overview] Message-ID: <20140722114607.GL15237@phenom.ffwll.local> (raw) In-Reply-To: <53CE2421.5040906-5C7GfCeVMHo@public.gmane.org> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote: > Am 22.07.2014 06:05, schrieb Dave Airlie: > >On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> wrote: > >>Signed-off-by: Maarten Lankhorst <maarten.lankhorst-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> > >>--- > >> drivers/gpu/drm/radeon/radeon.h | 15 +- > >> drivers/gpu/drm/radeon/radeon_device.c | 60 ++++++++- > >> drivers/gpu/drm/radeon/radeon_fence.c | 223 ++++++++++++++++++++++++++------ > >> 3 files changed, 248 insertions(+), 50 deletions(-) > >> > > From what I can see this is still suffering from the problem that we > >need to find a proper solution to, > > > >My summary of the issues after talking to Jerome and Ben and > >re-reading things is: > > > >We really need to work out a better interface into the drivers to be > >able to avoid random atomic entrypoints, > > Which is exactly what I criticized from the very first beginning. Good to > know that I'm not the only one thinking that this isn't such a good idea. I guess I've lost context a bit, but which atomic entry point are we talking about? Afaics the only one that's mandatory is the is fence->signaled callback to check whether a fence really has been signalled. It's used internally by the fence code to avoid spurious wakeups. Afaik that should be doable already on any hardware. If that's not the case then we can always track the signalled state in software and double-check in a worker thread before updating the sw state. And wrap this all up into a special fence class if there's more than one driver needing this. There is nothing else that forces callbacks from atomic contexts upon you. You can use them if you see it fit, but really if it doesn't suit your driver you can just ignore that part and do process based waits everywhere. > >I'm sure you have some ideas and I think you really need to > >investigate them to move this thing forward, > >even it if means some issues with android sync pts. > > Actually I think that TTMs fence interface already gave quite a good hint > how it might look like. I can only guess that this won't fit with the > Android stuff, otherwise I can't see a good reason why we didn't stick with > that. Well the current plan for i915<->radeon sync from Maarten is to use these atomic callbacks on the i915 side. So android didn't figure into this at all. Actually with android the entire implementation is kinda the platforms problem, the generic parts just give you a userspace interface and some means to stack up fences. > >but none of the two major drivers seem to want the interface as-is so > >something needs to give > > > >My major question is why we need an atomic callback here at all, what > >scenario does it cover? > > Agree totally. As far as I can see all current uses of the interface are of > the kind of waiting for a fence to signal. > > No need for any callback from one driver into another, especially not in > atomic context. If a driver needs such a functionality it should just start > up a kernel thread and do it's waiting there. > > This obviously shouldn't be an obstacle for pure hardware implementations > where one driver signals a semaphore another driver is waiting for, or a > high signal on an interrupt line directly wired between two chips. And I > think this is a completely different topic and not necessarily part of the > common fence interface we should currently focus on. It's for mixed hw/sw stuff where we want to poke the hw from the irq context (if possible) since someone forgot the wire. At least on the i915 side it boils down to one mmio write, and it's fairly pointless to launch a thread for that. So I haven't dug into ttm details but from the i915 side the current stuff and atomic semantics makes sense. Maybe we just need to wrap a bit more insulation around ttm-based drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-07-22 11:46 UTC|newest] Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-09 12:29 [PATCH 00/17] Convert TTM to the new fence interface Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 01/17] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 02/17] drm/ttm: kill off some members to ttm_validate_buffer Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 03/17] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 04/17] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 05/17] drm/ttm: call ttm_bo_wait while inside a reservation Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 06/17] drm/ttm: kill fence_lock Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 07/17] drm/nouveau: rework to new fence interface Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 08/17] drm/radeon: add timeout argument to radeon_fence_wait_seq Maarten Lankhorst 2014-07-09 12:29 ` Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 09/17] drm/radeon: use common fence implementation for fences Maarten Lankhorst 2014-07-09 12:57 ` Deucher, Alexander 2014-07-09 12:57 ` Deucher, Alexander 2014-07-09 13:23 ` [PATCH v2 " Maarten Lankhorst 2014-07-09 13:23 ` Maarten Lankhorst 2014-07-10 17:27 ` Alex Deucher 2014-07-10 17:27 ` Alex Deucher 2014-07-22 4:05 ` [PATCH " Dave Airlie 2014-07-22 4:05 ` Dave Airlie 2014-07-22 4:05 ` Dave Airlie 2014-07-22 8:43 ` Christian König 2014-07-22 8:43 ` Christian König 2014-07-22 11:46 ` Daniel Vetter [this message] 2014-07-22 11:46 ` Daniel Vetter 2014-07-22 11:52 ` Daniel Vetter 2014-07-22 11:52 ` Daniel Vetter 2014-07-22 11:57 ` Daniel Vetter 2014-07-22 11:57 ` Daniel Vetter 2014-07-22 12:19 ` Christian König 2014-07-22 12:19 ` Christian König 2014-07-22 13:26 ` [Nouveau] " Daniel Vetter 2014-07-22 13:26 ` Daniel Vetter 2014-07-22 13:45 ` Christian König 2014-07-22 13:45 ` Christian König 2014-07-22 14:44 ` [Nouveau] " Maarten Lankhorst 2014-07-22 14:44 ` Maarten Lankhorst 2014-07-22 15:02 ` [Nouveau] " Christian König 2014-07-22 15:18 ` Maarten Lankhorst 2014-07-22 15:17 ` Daniel Vetter 2014-07-22 15:17 ` Daniel Vetter 2014-07-22 15:35 ` [Nouveau] " Christian König 2014-07-22 15:35 ` Christian König 2014-07-22 15:42 ` Daniel Vetter 2014-07-22 15:42 ` Daniel Vetter 2014-07-22 15:59 ` Christian König 2014-07-22 15:59 ` Christian König 2014-07-22 16:21 ` Daniel Vetter 2014-07-22 16:21 ` Daniel Vetter 2014-07-22 16:39 ` Christian König 2014-07-22 16:39 ` Christian König 2014-07-22 16:52 ` Daniel Vetter 2014-07-22 16:52 ` Daniel Vetter 2014-07-22 16:43 ` Daniel Vetter 2014-07-22 16:43 ` Daniel Vetter 2014-07-23 6:40 ` Maarten Lankhorst 2014-07-23 6:40 ` Maarten Lankhorst 2014-07-23 6:52 ` Christian König 2014-07-23 6:52 ` Christian König 2014-07-23 7:02 ` [Nouveau] " Daniel Vetter 2014-07-23 7:02 ` Daniel Vetter 2014-07-23 7:06 ` [Nouveau] " Maarten Lankhorst 2014-07-23 7:06 ` Maarten Lankhorst 2014-07-23 7:09 ` Daniel Vetter 2014-07-23 7:09 ` Daniel Vetter 2014-07-23 7:15 ` Christian König 2014-07-23 7:15 ` Christian König 2014-07-23 7:32 ` [Nouveau] " Maarten Lankhorst 2014-07-23 7:32 ` Maarten Lankhorst 2014-07-23 7:41 ` Christian König 2014-07-23 7:41 ` Christian König 2014-07-23 7:26 ` [Nouveau] " Christian König 2014-07-23 7:26 ` Christian König 2014-07-23 7:31 ` Daniel Vetter 2014-07-23 7:31 ` Daniel Vetter 2014-07-23 7:37 ` Christian König 2014-07-23 7:37 ` Christian König 2014-07-23 7:51 ` [Nouveau] " Maarten Lankhorst 2014-07-23 7:51 ` Maarten Lankhorst 2014-07-23 7:58 ` [Nouveau] " Christian König 2014-07-23 7:58 ` Christian König 2014-07-23 8:07 ` [Nouveau] " Daniel Vetter 2014-07-23 8:07 ` Daniel Vetter 2014-07-23 8:20 ` [Nouveau] " Christian König 2014-07-23 8:20 ` Christian König 2014-07-23 8:25 ` Maarten Lankhorst 2014-07-23 8:25 ` Maarten Lankhorst 2014-07-23 8:42 ` [Nouveau] " Daniel Vetter 2014-07-23 8:42 ` Daniel Vetter 2014-07-23 8:46 ` Christian König 2014-07-23 8:46 ` Christian König 2014-07-23 8:54 ` [Nouveau] " Daniel Vetter 2014-07-23 8:54 ` Daniel Vetter 2014-07-23 9:27 ` [Nouveau] " Christian König 2014-07-23 9:27 ` Christian König 2014-07-23 9:30 ` [Nouveau] " Daniel Vetter 2014-07-23 9:30 ` Daniel Vetter 2014-07-23 9:36 ` [Nouveau] " Christian König 2014-07-23 9:36 ` Christian König 2014-07-23 9:38 ` [Nouveau] " Maarten Lankhorst 2014-07-23 9:38 ` Maarten Lankhorst 2014-07-23 9:39 ` Christian König 2014-07-23 9:39 ` Christian König 2014-07-23 9:39 ` [Nouveau] " Daniel Vetter 2014-07-23 9:39 ` Daniel Vetter 2014-07-23 9:44 ` Daniel Vetter 2014-07-23 9:44 ` Daniel Vetter 2014-07-23 9:47 ` [Nouveau] " Christian König 2014-07-23 9:47 ` Christian König 2014-07-23 9:52 ` Daniel Vetter 2014-07-23 9:52 ` Daniel Vetter 2014-07-23 9:55 ` [Nouveau] " Maarten Lankhorst 2014-07-23 9:55 ` Maarten Lankhorst 2014-07-23 10:13 ` [Nouveau] " Christian König 2014-07-23 10:13 ` Christian König 2014-07-23 10:52 ` [Nouveau] " Daniel Vetter 2014-07-23 10:52 ` Daniel Vetter 2014-07-23 12:36 ` Christian König 2014-07-23 12:36 ` Christian König 2014-07-23 12:42 ` Daniel Vetter 2014-07-23 12:42 ` Daniel Vetter 2014-07-23 13:16 ` Maarten Lankhorst 2014-07-23 13:16 ` Maarten Lankhorst 2014-07-23 14:05 ` [Nouveau] " Maarten Lankhorst 2014-07-23 14:05 ` Maarten Lankhorst 2014-07-24 13:47 ` [Nouveau] " Christian König 2014-07-24 13:47 ` Christian König 2014-07-23 8:01 ` Daniel Vetter 2014-07-23 8:01 ` Daniel Vetter 2014-07-23 8:31 ` Christian König 2014-07-23 8:31 ` Christian König 2014-07-23 12:35 ` Rob Clark 2014-07-23 12:35 ` Rob Clark 2014-07-22 14:05 ` Maarten Lankhorst 2014-07-22 14:24 ` Christian König 2014-07-22 14:27 ` Maarten Lankhorst 2014-07-22 14:39 ` Christian König 2014-07-22 14:47 ` Maarten Lankhorst 2014-07-22 15:16 ` Christian König 2014-07-22 15:19 ` Daniel Vetter 2014-07-22 15:19 ` Daniel Vetter 2014-07-22 15:42 ` Alex Deucher 2014-07-22 15:42 ` Alex Deucher 2014-07-22 15:48 ` Daniel Vetter 2014-07-22 15:48 ` Daniel Vetter 2014-07-22 19:14 ` Jesse Barnes 2014-07-22 19:14 ` Jesse Barnes 2014-07-23 9:47 ` [Nouveau] " Daniel Vetter 2014-07-23 9:47 ` Daniel Vetter 2014-07-23 15:37 ` [Nouveau] " Jesse Barnes 2014-07-23 15:37 ` Jesse Barnes 2014-07-22 11:51 ` Maarten Lankhorst 2014-07-22 11:51 ` Maarten Lankhorst 2014-07-09 12:29 ` [PATCH 10/17] drm/qxl: rework to new fence interface Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 11/17] drm/vmwgfx: get rid of different types of fence_flags entirely Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 12/17] drm/vmwgfx: rework to new fence interface Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 13/17] drm/ttm: flip the switch, and convert to dma_fence Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 14/17] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 15/17] drm/radeon: use rcu waits in some ioctls Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 16/17] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab Maarten Lankhorst 2014-07-09 12:30 ` [PATCH 17/17] drm/ttm: use rcu in core ttm Maarten Lankhorst 2014-07-09 13:09 ` [PATCH 00/17] Convert TTM to the new fence interface Mike Lothian 2014-07-09 13:21 ` Maarten Lankhorst 2014-07-09 13:21 ` Maarten Lankhorst 2014-07-10 21:37 ` Thomas Hellström 2014-07-10 21:37 ` Thomas Hellström
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=20140722114607.GL15237@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=airlied@gmail.com \ --cc=alexander.deucher@amd.com \ --cc=bskeggs@redhat.com \ --cc=christian.koenig@amd.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maarten.lankhorst@canonical.com \ --cc=nouveau@lists.freedesktop.org \ --cc=thellstrom@vmware.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.