search for: lpeltonen

From: Lauri Peltonen <lpeltonen at nvidia.com> Other methods in this file suggest this is the correct way to retrieve the engine pointer. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- 1 file changed...

From: Lauri Peltonen <lpeltonen at nvidia.com> Notify interrupt is only used for cyclestats. We can just clear it and avoid an "unknown stat" error that gets printed to dmesg otherwise. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---...

On Fri, Sep 26, 2014 at 01:00:12PM +0300, Lauri Peltonen wrote: > Allow user space to provide an explicit sync fence fd when exporting > a dma-buf from gem handle. The fence will be stored as the explicit > fence to the reservation object. > > Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> All existing userspace treats dma_bufs as long-lived objects. Well, all the userspace that expects implicit syncing, afaik Android shovels lots of dma-bufs around all the time (since ion is using them as it's native buffer handles). So adding an exclusive fence once at expor...

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

Allow user space to provide an explicit sync fence fd when exporting a dma-buf from gem handle. The fence will be stored as the explicit fence to the reservation object. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drivers/gpu/drm/drm_prime.c | 41 +++++++++++++++++++++++++++++++++-------- include/uapi/drm/drm.h | 9 ++++++++- 2 files changed, 41 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 2807a77..c69df2e 100644 ---...

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

...or sync_pt objects, and without implementing the sync_timeline_ops interface. Modify the sync driver debug code to not assume that every 'struct fence' (that is associated with a 'struct sync_fence') is embedded within a 'struct sync_pt'. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drivers/staging/android/sw_sync.c | 3 ++- drivers/staging/android/sync.c | 34 ++++++++++++++++++--------------- drivers/staging/android/sync.h | 11 ++++++----- drivers/staging/android/sync_debug.c | 37 +++++++++++++++++------------------- 4 files changed,...

...;treding at nvidia.com> Add a new nouveau_pushbuf_kick_fence() function that takes and emits a sync fence FD. The fence FD can be waited on, or merged with other fence FDs, or passed back to the kernel as a prerequisite for a subsequent HW operation. Based heavily on work by Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Thierry Reding <treding at nvidia.com> --- For the kernel patches that add the new IOCTL, see the series at: https://patchwork.freedesktop.org/series/36361/ include/drm/nouveau_drm.h | 23 ++++++++ nouveau/nouveau.h | 2 + nouveau/pushbuf.c...

Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> --- drm/nouveau_bo.c | 8 ++++---- drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47 +++++++++++++++++++++++++++++++++++++++------- drm/nouveau_gem.h | 6 ++++-- drm/nouveau_ttm.c | 8 ++++----...

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

Riley (CCed) and I will be at Plumbers in a couple weeks. There is a session on sync planned in the Android track, and of course we'll be available to chat. On Thu, Oct 2, 2014 at 1:44 PM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Oct 02, 2014 at 05:59:51PM +0300, Lauri Peltonen wrote: > > +Rom who seems to be presenting about mainlining android sync at linux >

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

Thanks Daniel for your input! On Mon, Sep 29, 2014 at 09:43:02AM +0200, Daniel Vetter wrote: > On Fri, Sep 26, 2014 at 01:00:05PM +0300, Lauri Peltonen wrote: > > (2) Stop automatically storing fences to the buffers that user space wants to > > synchronize explicitly. > > The problem with this approach is that you then need hw faulting to make > sure the memory is

+Rom who seems to be presenting about mainlining android sync at linux plumbers On Wed, Oct 01, 2014 at 05:58:52PM +0200, Maarten Lankhorst wrote: > You could neuter 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