search for: syncpt

...| 12 ++- drivers/gpu/host1x/fence.c | 202 +++++++++++++++++++++++++++++++++++++ drivers/gpu/host1x/fence.h | 28 +++++ drivers/gpu/host1x/hw/channel_hw.c | 36 +++++-- drivers/gpu/host1x/intr.c | 11 +- drivers/gpu/host1x/intr.h | 8 +- drivers/gpu/host1x/syncpt.c | 2 + include/linux/host1x.h | 12 ++- include/uapi/drm/tegra_drm.h | 10 +- 12 files changed, 376 insertions(+), 29 deletions(-) create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h -- 2.15.1

...| 12 ++- drivers/gpu/host1x/fence.c | 202 +++++++++++++++++++++++++++++++++++++ drivers/gpu/host1x/fence.h | 28 +++++ drivers/gpu/host1x/hw/channel_hw.c | 36 +++++-- drivers/gpu/host1x/intr.c | 11 +- drivers/gpu/host1x/intr.h | 8 +- drivers/gpu/host1x/syncpt.c | 2 + include/linux/host1x.h | 12 ++- 10 files changed, 302 insertions(+), 11 deletions(-) create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig index 91916326957f...

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

...es, on the other hand, would only be used to guarantee that we don't swap out or unmap something that the GPU might be accessing. We never need to wait for those fences (except when swapping or unmapping), so we can be conservative without hurting performance. > Imo de-staging the android syncpt stuff needs to happen first, before drivers > can use it. Since non-staging stuff really shouldn't depend upon code from > staging. Fully agree. I thought the best way towards that would be to show some driver code that _would_ use it. :) > I'm all for adding explicit syncing....

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

...case where everything fits. If I understood correctly, this would be exactly the same as what I called the "default working set" above. On Android we don't care much about finer grained working sets either, because of UMA and no swapping. > > > Imo de-staging the android syncpt stuff needs to happen first, before drivers > > > can use it. Since non-staging stuff really shouldn't depend upon code from > > > staging. > > > > Fully agree. I thought the best way towards that would be to show some driver > > code that _would_ use it. :...

...ement the buffer svm model in ocl2. Mostly because we expect that applications won't get the more fine-grained buffer list right anyway. And this kind of gang-scheduling of working set sizes should be more efficient for the usual case where everything fits. > > Imo de-staging the android syncpt stuff needs to happen first, before drivers > > can use it. Since non-staging stuff really shouldn't depend upon code from > > staging. > > Fully agree. I thought the best way towards that would be to show some driver > code that _would_ use it. :) Oh, there's the us...

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

...ell with ocl the SVM buffer working set sizes are attached to an ocl context, but I don't think there'll be more than one of those around really (except maybe when different libraries all use ocl, but don't work together on the same data). > > > > Imo de-staging the android syncpt stuff needs to happen first, before drivers > > > > can use it. Since non-staging stuff really shouldn't depend upon code from > > > > staging. > > > > > > Fully agree. I thought the best way towards that would be to show some driver > > > co...

...epts. I'd like to think that my > > patches only use the parts of the android sync driver that genuinely are > > missing from the drm fence model: allowing user space to operate on fence > > objects that are independent of buffer objects. > > Imo de-staging the android syncpt stuff needs to happen first, before > drivers can use it. Since non-staging stuff really shouldn't depend upon > code from staging. > > > The last two patches are mocks that show how (2) and (3) might work out. I > > haven't done any testing with them yet. Before goi...

...ome of the drm fence concepts. I'd like to think that my > patches only use the parts of the android sync driver that genuinely are > missing from the drm fence model: allowing user space to operate on fence > objects that are independent of buffer objects. Imo de-staging the android syncpt stuff needs to happen first, before drivers can use it. Since non-staging stuff really shouldn't depend upon code from staging. > The last two patches are mocks that show how (2) and (3) might work out. I > haven't done any testing with them yet. Before going any further, I'd l...

...fer working > set sizes are attached to an ocl context, but I don't think there'll be > more than one of those around really (except maybe when different > libraries all use ocl, but don't work together on the same data). > > > > > > Imo de-staging the android syncpt stuff needs to happen first, > before drivers > > > > > can use it. Since non-staging stuff really shouldn't depend upon > code from > > > > > staging. > > > > > > > > Fully agree. I thought the best way towards that would be to show...

...ike to think that my >>> patches only use the parts of the android sync driver that genuinely are >>> missing from the drm fence model: allowing user space to operate on fence >>> objects that are independent of buffer objects. >> >> Imo de-staging the android syncpt stuff needs to happen first, before >> drivers can use it. Since non-staging stuff really shouldn't depend upon >> code from staging. >> >>> The last two patches are mocks that show how (2) and (3) might work out. I >>> haven't done any testing with them...

...r *relocs = - (void __user *)(uintptr_t)args->relocs; - struct drm_tegra_waitchk __user *waitchks = - (void __user *)(uintptr_t)args->waitchks; + struct drm_tegra_cmdbuf __user *cmdbufs; + struct drm_tegra_reloc __user *relocs; + struct drm_tegra_waitchk __user *waitchks; struct drm_tegra_syncpt syncpt; struct host1x_job *job; int err; @@ -354,6 +351,10 @@ int tegra_drm_submit(struct tegra_drm_context *context, job->class = context->client->base.class; job->serialize = true; + cmdbufs = u64_to_user_ptr(args->cmdbufs); + relocs = u64_to_user_ptr(args->relocs); +...

...r *relocs = - (void __user *)(uintptr_t)args->relocs; - struct drm_tegra_waitchk __user *waitchks = - (void __user *)(uintptr_t)args->waitchks; + struct drm_tegra_cmdbuf __user *cmdbufs; + struct drm_tegra_reloc __user *relocs; + struct drm_tegra_waitchk __user *waitchks; struct drm_tegra_syncpt syncpt; struct host1x_job *job; int err; @@ -354,6 +351,10 @@ int tegra_drm_submit(struct tegra_drm_context *context, job->class = context->client->base.class; job->serialize = true; + cmdbufs = u64_to_user_ptr(args->cmdbufs); + relocs = u64_to_user_ptr(args->relocs); +...

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