search for: enable_signalling

On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: >> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? > It doesn't need to be completely reliable, or finish immediately. > > And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. I raised this already somewher...

...ever calling signaling a fence at all before dropping the last refcount to it. > This allows you to keep interrupts disabled when you don't need them. Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? >>> Agreed that any shared locks are out of the way (especially stuff like >>> dev->struct_mutex or other non-strictly driver-private stuff, i915 is >>> really bad here still). >> Yeah that...

..., schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst >> <maarten.lankhorst at canonical.com> wrote: >>>> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? >>> It doesn't need to be completely reliable, or finish immediately. >>> >>> And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. >&gt...

Am 23.07.2014 11:55, schrieb Maarten Lankhorst: > op 23-07-14 11:47, Christian K?nig schreef: >> Am 23.07.2014 11:44, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter <daniel.vetter at ffwll.ch> wrote: >>>> The scheduler needs to keep track of a lot of fences, so I think we'll >>>> have to register callbacks, not a

...7.2014 09:09, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >>> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? >> It doesn't need to be completely reliable, or finish immediately. >> >> And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. > I raised this...

...to the scheme used by i915 as I'll have for converting to the one used by radeon. If it would fit at all. I guess for radeon we just have to add tons of insulation by punting all callbacks to work items so that radeon can do whatever it wants. Plus start a delayed_work based fallback when ->enable_signalling is called to make sure we work on platforms that lack interrupts. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

...g signaling a fence at all before dropping the last refcount to it. >> This allows you to keep interrupts disabled when you don't need them. > > Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? It doesn't need to be completely reliable, or finish immediately. And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. >>>> Agreed that any shared lock...

...ignaling a fence at all before dropping the last refcount to it. >>> This allows you to keep interrupts disabled when you don't need them. >> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? > It doesn't need to be completely reliable, or finish immediately. > > And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. > >>>>> Agree...

...g interrupts as well as a chance for any driver to do necessary lockup handling. Christian. > I guess for radeon we just have to add tons of insulation by punting > all callbacks to work items so that radeon can do whatever it wants. > Plus start a delayed_work based fallback when ->enable_signalling is > called to make sure we work on platforms that lack interrupts. > -Daniel

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers

Hi, On 8/31/23 13:18, Danilo Krummrich wrote: > On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellstr?m (Intel) wrote: >> Hi! >> >> On 8/30/23 17:00, Danilo Krummrich wrote: >>> On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellstr?m (Intel) wrote: >>>> On 8/30/23 14:49, Danilo Krummrich wrote: >>>>> Hi Thomas, >>>>>