[RFC] Explicit synchronization for Nouveau

2014-09-26 Thread Lauri Peltonen
synchronization model? Do you think we could use the android sync_fence for passing fences between user space? Or did you have something else in mind for explicit sync in the drm world? Thanks, Lauri Lauri Peltonen (7): android: Support creating sync fence from drm fences drm/nouveau: Split

[RFC PATCH 1/7] android: Support creating sync fence from drm fences

2014-09-26 Thread Lauri Peltonen
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 --- drivers/staging/android/sw_sync.c| 3 ++- drivers/staging/android/sync.c | 34

[RFC PATCH 2/7] drm/nouveau: Split nouveau_fence_sync

2014-09-26 Thread Lauri Peltonen
Split nouveau_fence_sync to two functions: * nouveau_fence_sync, which only adds a fence wait to the channel command stream, and * nouveau_bo_sync, which gets the fences from the reservation object and passes them to nouveau_fence_sync. Signed-off-by: Lauri Peltonen --- drm

[RFC PATCH 3/7] drm/nouveau: Add fence fd helpers

2014-09-26 Thread Lauri Peltonen
on the CPU. Add missing fence_value_str and timeline_value_str callbacks to nouveau fence_ops. Signed-off-by: Lauri Peltonen --- drm/nouveau_fence.c | 71 - drm/nouveau_fence.h | 2 ++ 2 files changed, 72 insertions(+), 1 deletion(-) diff --git

[RFC PATCH 4/7] drm/nouveau: Support fence fd's at kickoff

2014-09-26 Thread Lauri Peltonen
Add a new NOUVEAU_GEM_PUSHBUF_2 ioctl that accepts and emits a sync fence fd from/to user space if the user space requests it by passing corresponding flags. Signed-off-by: Lauri Peltonen --- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 46

[RFC PATCH 5/7] libdrm: nouveau: Support fence fds

2014-09-26 Thread Lauri Peltonen
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 fd's, or passed back to kernel as a prerquisite for a subsequent hw operation. Signed-off-by: Lauri Peltonen --- include/drm/nouveau_drm.h | 10

[RFC PATCH 6/7] drm/nouveau: Support marking buffers for explicit sync

2014-09-26 Thread Lauri Peltonen
Do not attach fences automatically to buffers that are marked for explicit synchronization. Signed-off-by: Lauri Peltonen --- drm/nouveau_bo.c | 8 drm/nouveau_bo.h | 4 ++-- drm/nouveau_drm.c | 1 + drm/nouveau_gem.c | 47

[RFC PATCH 7/7] drm/prime: Support explicit fence on export

2014-09-26 Thread Lauri Peltonen
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 --- drivers/gpu/drm/drm_prime.c | 41 + include/uapi

[RFC] Explicit synchronization for Nouveau

2014-10-01 Thread Lauri Peltonen
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 explici

[RFC PATCH 7/7] drm/prime: Support explicit fence on export

2014-10-01 Thread Lauri Peltonen
On Mon, Sep 29, 2014 at 09:46:48AM +0200, Daniel Vetter wrote: > 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 exp

[RFC] Explicit synchronization for Nouveau

2014-10-02 Thread Lauri Peltonen
be dealt with later as an optimization. On Wed, Oct 01, 2014 at 07:27:21PM +0200, Daniel Vetter wrote: > On Wed, Oct 01, 2014 at 06:14:16PM +0300, Lauri Peltonen wrote: > > Implicit fences attached to individual buffers are one way for residency > > management. Do you think a worki

[RFC] Explicit synchronization for Nouveau

2014-10-06 Thread Lauri Peltonen
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 s