search for: fence_signaled

...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...). Ho...

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 somewhere else, but should we have some common infrastr...

...m/ttm_bo_api.h> > #include <ttm/ttm_bo_driver.h> > @@ -113,9 +114,6 @@ extern int radeon_hard_reset; > #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 > @@ -347,12 +345,15 @@ struct radeon_fence_driver { > }; > > struct radeon_fence { > + struct fence base; > + > struct radeon_d...

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

...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 somewhere else, but sho...

...: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 mma...

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

op 19-05-14 14:30, Christian K?nig schreef: > Am 19.05.2014 12:10, schrieb Maarten Lankhorst: >> op 19-05-14 10:27, Christian K?nig schreef: >>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>> [SNIP] >>> The problem here is that the whole approach collides with the way we do reset handling from a conceptual point of view. Every IOCTL or other call chain into

...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 primi...

...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...). Holdi...

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

...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 somewhere else, but should we have some...

...;> 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...

Am 19.05.2014 15:35, schrieb Maarten Lankhorst: > op 19-05-14 14:30, Christian K?nig schreef: >> Am 19.05.2014 12:10, schrieb Maarten Lankhorst: >>> op 19-05-14 10:27, Christian K?nig schreef: >>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>>> [SNIP] >>>> The problem here is that the whole approach collides with the way >>>>

...#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; &gt...

On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: > Am 22.07.2014 13:57, schrieb Daniel Vetter: > >On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: > >>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

op 22-07-14 15:45, Christian K?nig schreef: > Am 22.07.2014 15:26, schrieb Daniel Vetter: >> On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian K?nig wrote: >>> Am 22.07.2014 13:57, schrieb Daniel Vetter: >>>> On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote: >>>>> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:

...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 locking pr...

...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 as t...

...+#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.lock...