search for: sync_fence

Modify sync_fence_create to accept an array of 'struct fence' objects. This will allow drm drivers to create sync_fence objects and pass sync fd's between user space with minimal modifications, without ever creating sync_timeline or sync_pt objects, and without implementing the sync_timeline_ops interfac...

...e difficult. I have written a prototype that demonstrates (1) by adding explicit sync fd support to Nouveau. It's not a lot of code, because I only use a relatively small subset of the android sync driver functionality. Thanks to Maarten's rewrite, all I need to do is to allow creating a sync_fence from a drm fence in order to pass it to user space. I don't need to use sync_pt or sync_timeline, or fill in sync_timeline_ops. I can see why the upstream has been reluctant to de-stage the android sync driver in its current form, since (even though it now builds on struct fence) it still dup...

...er implicit fences by always attaching the fences as > shared when explicit syncing is used. This would work correctly with > eviction, and wouldn't cause any unneeded syncing. :) Yes, that will probably work! So, just to reiterate that I understood you and Daniel correctly: - de-stage sync_fence and it's user space API (the tedious part) - add dma-buf ioctls for extracting and attaching explicit fences - Nouveau specific: allow flagging gem buffers for explicit sync - do not check pre-fences from explicitly synced buffers at submit - continue to attach a shared fence after submit...

...ing the fences as > > shared when explicit syncing is used. This would work correctly with > > eviction, and wouldn't cause any unneeded syncing. :) > > Yes, that will probably work! So, just to reiterate that I understood you and > Daniel correctly: > > - de-stage sync_fence and it's user space API (the tedious part) > - add dma-buf ioctls for extracting and attaching explicit fences > - Nouveau specific: allow flagging gem buffers for explicit sync > - do not check pre-fences from explicitly synced buffers at submit > - continue to attach a shared...

...d when explicit syncing is used. This would work correctly with > > > eviction, and wouldn't cause any unneeded syncing. :) > > > > Yes, that will probably work! So, just to reiterate that I understood > you and > > Daniel correctly: > > > > - de-stage sync_fence and it's user space API (the tedious part) > > - add dma-buf ioctls for extracting and attaching explicit fences > > - Nouveau specific: allow flagging gem buffers for explicit sync > > - do not check pre-fences from explicitly synced buffers at submit > > - continue...

...errably manpages. This all sounds very similar to what we'd like to do! Maybe we can move forward with these parts, and continue to attach fences at submit until we have a satisfactory solution for the pinning problem? I'd like to understand what are the concrete steps to de-stage struct sync_fence, since that's the first thing that needs to be done. For example, what do you mean by "de-cluttering the internal interfaces"? Just that we'd move the sync_fence parts from drivers/staging/android/sync.c to, say, drivers/dma-buf/sync-fence.c ? Would we still leave a copy of the...

...prototype that demonstrates (1) by adding explicit sync fd > > support to Nouveau. It's not a lot of code, because I only use a relatively > > small subset of the android sync driver functionality. Thanks to Maarten's > > rewrite, all I need to do is to allow creating a sync_fence from a drm fence in > > order to pass it to user space. I don't need to use sync_pt or sync_timeline, > > or fill in sync_timeline_ops. > > > > I can see why the upstream has been reluctant to de-stage the android sync > > driver in its current form, since (even...

...pinning problem? Yeah, that's our plan for i915 too. First add explicit fences, then figure out whether we need to be better at neutering the implicit fences, in case and only where it really gets in the way. > I'd like to understand what are the concrete steps to de-stage struct > sync_fence, since that's the first thing that needs to be done. For example, > what do you mean by "de-cluttering the internal interfaces"? Just that we'd > move the sync_fence parts from drivers/staging/android/sync.c to, say, > drivers/dma-buf/sync-fence.c ? Would we still leav...

...have written a prototype that demonstrates (1) by adding explicit sync fd > support to Nouveau. It's not a lot of code, because I only use a relatively > small subset of the android sync driver functionality. Thanks to Maarten's > rewrite, all I need to do is to allow creating a sync_fence from a drm fence in > order to pass it to user space. I don't need to use sync_pt or sync_timeline, > or fill in sync_timeline_ops. > > I can see why the upstream has been reluctant to de-stage the android sync > driver in its current form, since (even though it now builds on s...

...e that demonstrates (1) by adding explicit sync fd >>> support to Nouveau. It's not a lot of code, because I only use a relatively >>> small subset of the android sync driver functionality. Thanks to Maarten's >>> rewrite, all I need to do is to allow creating a sync_fence from a drm fence in >>> order to pass it to user space. I don't need to use sync_pt or sync_timeline, >>> or fill in sync_timeline_ops. >>> >>> I can see why the upstream has been reluctant to de-stage the android sync >>> driver in its current form...

On Thu, Oct 02, 2014 at 10:44:05PM +0200, Daniel Vetter wrote: > On Thu, Oct 02, 2014 at 05:59:51PM +0300, Lauri Peltonen wrote: > > Yes, that will probably work! So, just to reiterate that I understood you and > > Daniel correctly: > > > > - de-stage sync_fence and it's user space API (the tedious part) > > - add dma-buf ioctls for extracting and attaching explicit fences > > - Nouveau specific: allow flagging gem buffers for explicit sync > > - do not check pre-fences from explicitly synced buffers at submit > > - continu...

...IME export function which must be used mandatorily by GEM @@ -401,6 +403,24 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev, struct drm_gem_object *obj; int ret = 0; struct dma_buf *dmabuf; + struct fence *fence = NULL; + + if (flags & DRM_SYNC_FD) { +#ifdef CONFIG_SYNC + struct sync_fence *sf = sync_fence_fdget(*prime_fd); + if (!sf) + return -ENOENT; + if (sf->num_fences != 1) { + sync_fence_put(sf); + return -EINVAL; + } + fence = fence_get(sf->cbs[0].sync_pt); + sync_fence_put(sf); + flags &= ~DRM_SYNC_FD; +#else + return -ENODEV; +#endif + } mutex_lock...

...orily by GEM > @@ -401,6 +403,24 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev, > struct drm_gem_object *obj; > int ret = 0; > struct dma_buf *dmabuf; > + struct fence *fence = NULL; > + > + if (flags & DRM_SYNC_FD) { > +#ifdef CONFIG_SYNC > + struct sync_fence *sf = sync_fence_fdget(*prime_fd); > + if (!sf) > + return -ENOENT; > + if (sf->num_fences != 1) { > + sync_fence_put(sf); > + return -EINVAL; > + } > + fence = fence_get(sf->cbs[0].sync_pt); > + sync_fence_put(sf); > + flags &= ~DRM_SYNC_FD; > +#...

...s lib/igt_kmod: kmod already supplies a cooked error code lib/sw_sync: Provide compatiblity stubs for old headers tests/perf: Remove duplicate NSEC_PER_SEC define lib/sw_sync: Bring sync_wait() API into line lib/sw_sync: Indicate that sync_merge() operates and create a sync_fence lib/sw_sync: Rename sync_fence_create() lib/sw_sync: Use timeline/fence instead of generic fd lib/selftest: Query module parameter for error code. lib: Kick all fbcon stubs/intel_bufmgr: Suppress GCC compilation warnings igt/kms_addfb_basic: Try changing tiling o...