search for: syncpts

From: Thierry Reding <treding at nvidia.com> This set of patches adds support for fences to Tegra DRM and complements the fence FD support for Nouveau. Technically this isn't necessary for a fence-based synchronization loop with Nouveau because the KMS core takes care of all that, but engines behind host1x can use the IOCTL extensions provided here to emit fence FDs that in turn can be

From: Mikko Perttunen <mperttunen at nvidia.com> Add an implementation of DMA fences backed by Host1x syncpoints, an interface to specify a prefence for job submissions. Before submission, prefences containing only Host1x syncpoints are waited by pushing wait commands to CDMA, whereas other fences are CPU-waited. Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com>

On Tue, Jul 22, 2014 at 11:19 AM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Tue, Jul 22, 2014 at 4:39 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Am 22.07.2014 16:27, schrieb Maarten Lankhorst: >> >>> op 22-07-14 16:24, Christian K?nig schreef: >>>>> >>>>> No, you really shouldn't be doing much in the

...new > atomic stuff. Again we need an in fence to wait for (one for each > buffer) and an out fence. The later can easily be implemented by > extending struct drm_event, which means not a single driver code line > needs to be changed for this. > > - For de-staging android syncpts we need to de-clutter the internal > interfaces and also review all the ioctls exposed. Like you say it > should be just the userspace interface for struct drm_fence. Also, it > needs testcases and preferrably manpages. This all sounds very similar to what we'd like to do! Mayb...

...t; things to best fit their own task graphs. The app can decide how to > deal with dependencies and synchronization explicitly instead of > blocking the queues in the kernel for everyone. Anyway, this is > getting off topic. Well there's explicit fences as used in opencl and android syncpts. My plan is actually to support that in i915 using Maarten's struct fence stuff (and there's just a very trivial patch for the android stuff in merging needed to get there). What doesn't work is fences created behind the kernel's back purely in userspace by giving shared memory loca...

...e to wait for (one for each > > > buffer) and an out fence. The later can easily be implemented by > > > extending struct drm_event, which means not a single driver code line > > > needs to be changed for this. > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > interfaces and also review all the ioctls exposed. Like you say it > > > should be just the userspace interface for struct drm_fence. Also, it > > > needs testcases and preferrably manpages. > > > > This all soun...

...Again we need an in fence to wait for (one for each > > buffer) and an out fence. The later can easily be implemented by > > extending struct drm_event, which means not a single driver code line > > needs to be changed for this. > > > > - For de-staging android syncpts we need to de-clutter the internal > > interfaces and also review all the ioctls exposed. Like you say it > > should be just the userspace interface for struct drm_fence. Also, it > > needs testcases and preferrably manpages. > > This all sounds very similar to what w...

...ir own task graphs. The app can decide how to > > deal with dependencies and synchronization explicitly instead of > > blocking the queues in the kernel for everyone. Anyway, this is > > getting off topic. > > Well there's explicit fences as used in opencl and android syncpts. My > plan is actually to support that in i915 using Maarten's struct fence > stuff (and there's just a very trivial patch for the android stuff in > merging needed to get there). What doesn't work is fences created > behind the kernel's back purely in userspace by givin...

...ch > > > > buffer) and an out fence. The later can easily be implemented by > > > > extending struct drm_event, which means not a single driver code line > > > > needs to be changed for this. > > > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > > interfaces and also review all the ioctls exposed. Like you say it > > > > should be just the userspace interface for struct drm_fence. Also, it > > > > needs testcases and preferrably manpages. > > > &gt...

...new > atomic stuff. Again we need an in fence to wait for (one for each > buffer) and an out fence. The later can easily be implemented by > extending struct drm_event, which means not a single driver code line > needs to be changed for this. > > - For de-staging android syncpts we need to de-clutter the internal > interfaces and also review all the ioctls exposed. Like you say it > should be just the userspace interface for struct drm_fence. Also, it > needs testcases and preferrably manpages. > > Unfortunately it looks like Intel won't do this a...

...nly worth it together with the new atomic stuff. Again we need an in fence to wait for (one for each buffer) and an out fence. The later can easily be implemented by extending struct drm_event, which means not a single driver code line needs to be changed for this. - For de-staging android syncpts we need to de-clutter the internal interfaces and also review all the ioctls exposed. Like you say it should be just the userspace interface for struct drm_fence. Also, it needs testcases and preferrably manpages. Unfortunately it looks like Intel won't do this all for you due to a bunch...

...buffer) and an out fence. The later can easily be implemented by > > > > > extending struct drm_event, which means not a single driver code > line > > > > > needs to be changed for this. > > > > > > > > > > - For de-staging android syncpts we need to de-clutter the internal > > > > > interfaces and also review all the ioctls exposed. Like you say > it > > > > > should be just the userspace interface for struct drm_fence. > Also, it > > > > > needs testcases and preferrably manp...

...ff. Again we need an in fence to wait for (one for each >> buffer) and an out fence. The later can easily be implemented by >> extending struct drm_event, which means not a single driver code line >> needs to be changed for this. >> >> - For de-staging android syncpts we need to de-clutter the internal >> interfaces and also review all the ioctls exposed. Like you say it >> should be just the userspace interface for struct drm_fence. Also, it >> needs testcases and preferrably manpages. >> >> Unfortunately it looks like Int...

...+ waitchks = u64_to_user_ptr(args->waitchks); + while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; struct host1x_bo *bo; @@ -389,7 +390,7 @@ int tegra_drm_submit(struct tegra_drm_context *context, goto fail; } - if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts, + if (copy_from_user(&syncpt, u64_to_user_ptr(args->syncpts), sizeof(syncpt))) { err = -EFAULT; goto fail; diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c index 9807bc9..fe3a4aa 100644 --- a/drivers/gpu/drm/vc4/vc4_bo.c +++ b/drivers/gpu/drm/vc4/vc4_bo....

...+ waitchks = u64_to_user_ptr(args->waitchks); + while (num_cmdbufs) { struct drm_tegra_cmdbuf cmdbuf; struct host1x_bo *bo; @@ -389,7 +390,7 @@ int tegra_drm_submit(struct tegra_drm_context *context, goto fail; } - if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts, + if (copy_from_user(&syncpt, u64_to_user_ptr(args->syncpts), sizeof(syncpt))) { err = -EFAULT; goto fail; diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c index 9807bc9..fe3a4aa 100644 --- a/drivers/gpu/drm/vc4/vc4_bo.c +++ b/drivers/gpu/drm/vc4/vc4_bo....

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 simple wait function. We must keep >> track of all the non-i915 fences for all oustanding batches. Also, the >> scheduler

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes