search for: fence_sign

...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 wanting to use exported fences don't call fence->signaled or >>>> fence->wait in atomic or interrupt context, and not with holding any global >>>> locking primitives (like mmap_sem etc...)...

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-&g...

...scary things in your is_signaled > handler. This is indeed a nice optimization, but nothing more. If you want to provide a is_signalled interface for atomic context then this should be optional, not mandatory. > > In case of enable_signaling it was the only sane solution, because > fence_signal can be called from irq context, and any calls after that to > fence_add_callback and fence_wait aren't allowed to do anything, so > fence_enable_sw_signaling and the default wait implementation must be > atomic. fence_wait itself doesn't have to be, so it's easy to grab >...

...ieb 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 wanting to use exported fences don't call fence->signaled or >> fence->wait in atomic or interrupt context, and not with holding any global >> locking primitives (like mmap_sem etc...). Holding locking primitives loc...

op 23-07-14 09:15, Christian K?nig schreef: > Am 23.07.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...

> Maybe I've mixed things up a bit in my description. There is > fence_signal which the implementor/exporter of a fence must call when > the fence is completed. If the exporter has an ->enable_signaling > callback it can delay that call to fence_signal for as long as it > wishes as long as enable_signaling isn't called yet. But that's just > the opti...

...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 wanting to use exported fences don't call fence->signaled or >>>>> fence->wait in atomic or interrupt context, and not with holding any global >>>>> locking primitives (like...

..._signaled >> handler. > > This is indeed a nice optimization, but nothing more. If you want to provide a is_signalled interface for atomic context then this should be optional, not mandatory. See below. >> In case of enable_signaling it was the only sane solution, because >> fence_signal can be called from irq context, and any calls after that to >> fence_add_callback and fence_wait aren't allowed to do anything, so >> fence_enable_sw_signaling and the default wait implementation must be >> atomic. fence_wait itself doesn't have to be, so it's easy t...

...an 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 wanting to use exported fences don't call fence->signaled or >>>>>> fence->wait in atomic or interrupt context, and not with holding any global >>>>>> locking p...

...14 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 wanting to use exported fences don't call fence->signaled or >>> fence->wait in atomic or interrupt context, and not with holding any >>> global >>> locking primitives (like mmap_sem etc...). H...

...>>>>> Ah thanks, I'll add that. >>>>> >>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>>>> .signaled = __radeon_fence_signaled, >>>>>> Do we still need those callback when we implemented the wait >>>>>> callback? >>>>> .get_timeline_name is used for debugging (trace events). >>>>> .signaled is the non-blocking call to check if the fence is >>>...

Am 23.07.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(...

...;> Ah thanks, I'll add that. >>>>>> >>>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>>>>>> .signaled = __radeon_fence_signaled, >>>>>>> Do we still need those callback when we implemented the wait callback? >>>>>> .get_timeline_name is used for debugging (trace events). >>>>>> .signaled is the non-blocking call to check if the fence is signaled or not. >>&g...

...> This is indeed a nice optimization, but nothing more. If you want to >> provide a is_signalled interface for atomic context then this should >> be optional, not mandatory. > See below. >>> In case of enable_signaling it was the only sane solution, because >>> fence_signal can be called from irq context, and any calls after >>> that to >>> fence_add_callback and fence_wait aren't allowed to do anything, so >>> fence_enable_sw_signaling and the default wait implementation must be >>> atomic. fence_wait itself doesn't have...

...#include <ttm/ttm_bo_api.h> > #include <ttm/ttm_bo_driver.h> > @@ -116,9 +117,6 @@ extern int radeon_deep_color; > #define RADEONFB_CONN_LIMIT 4 > #define RADEON_BIOS_NUM_SCRATCH 8 > > -/* fence seq are set to this number when signaled */ > -#define RADEON_FENCE_SIGNALED_SEQ 0LL > - > /* internal ring indices */ > /* r1xx+ has gfx CP ring */ > #define RADEON_RING_TYPE_GFX_INDEX 0 > @@ -350,12 +348,15 @@ struct radeon_fence_driver { > }; > > struct radeon_fence { > + struct fence base; > + > struct radeon_device *rdev;...

...so would boild down to adding a WARN_ON(in_interrupt) or so to fence_enable_sw_signalling. - Make fence->signaled optional (already the case) and don't implement it in readon (i.e. reduce this patch here). Only downside is that radeon needs to correctly (i.e. without races or so) call fence_signal. And the cross-driver synchronization might be a bit less efficient. Note that you can call fence_signal from wherever you want to, so hopefully that doesn't restrict your implementation. End result: No one calls into radeon from interrupt context, and this is guaranteed. Would that...

...N_ON(in_interrupt) or so to fence_enable_sw_signalling. >> >> - Make fence->signaled optional (already the case) and don't implement it >> in readon (i.e. reduce this patch here). Only downside is that radeon >> needs to correctly (i.e. without races or so) call fence_signal. And the >> cross-driver synchronization might be a bit less efficient. Note that >> you can call fence_signal from wherever you want to, so hopefully that >> doesn't restrict your implementation. >> >> End result: No one calls into radeon from interrupt...

...gt;> 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 wanting to use exported fences don't call fence->signaled or >>> fence->wait in atomic or interrupt context, and not with holding any global >>> locking primitives (like mmap_sem etc...). Holding lockin...

...need to agree to a minimum and save interface for all drivers. > Well I haven't yet seen a proposal that actually works. How about this: 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 wanting to use exported fences don't call fence->signaled or fence->wait in atomic or interrupt context, and not with holding any global locking primitives (like mmap_sem etc...). Holding locking primitives local to the driver is ok, as long...

...+#include <linux/fence.h> #include <ttm/ttm_bo_api.h> #include <ttm/ttm_bo_driver.h> @@ -116,9 +117,6 @@ extern int radeon_deep_color; #define RADEONFB_CONN_LIMIT 4 #define RADEON_BIOS_NUM_SCRATCH 8 -/* fence seq are set to this number when signaled */ -#define RADEON_FENCE_SIGNALED_SEQ 0LL - /* internal ring indices */ /* r1xx+ has gfx CP ring */ #define RADEON_RING_TYPE_GFX_INDEX 0 @@ -350,12 +348,15 @@ struct radeon_fence_driver { }; struct radeon_fence { + struct fence base; + struct radeon_device *rdev; - struct kref kref; /* protected by radeon_fence....