Hi Maarten, 2016-03-24 Maarten Lankhorst <maarten.lankho...@linux.intel.com>:
> Hey, > > Op 23-03-16 om 19:47 schreef Gustavo Padovan: > > From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> > > > > Hi, > > > > This is a first proposal to discuss the addition of in-fences support > > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > > in DRM drivers. The new struct fence_collection contains a array with all > > fences that a atomic commit needs to wait on > > > > /** > > * struct fence_collection - aggregate fences together > > * @num_fences: number of fence in the collection. > > * @user_data: user data. > > * @func: user callback to put user data. > > * @fences: array of @num_fences fences. > > */ > > struct fence_collection { > > int num_fences; > > void *user_data; > > collection_put_func_t func; > > struct fence *fences[]; > > }; > > > > > > The fence_collection is allocated and filled by sync_file_fences_get() and > > atomic_commit helpers can use fence_collection_wait() to wait the fences to > > signal. > > > > These patches depends on the sync ABI rework: > > > > https://www.spinics.net/lists/dri-devel/msg102795.html > > > > and the patch to de-stage the sync framework: > > > > https://www.spinics.net/lists/dri-devel/msg102799.html > > > > > > I also hacked together some sync support into modetest for testing: > > > > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic > > > Why did you choose to add fence_collection, rather than putting sync_file in > state? > > There used to be a sync_fence_wait function, which would mean you'd have > everything you need. We discussed this on #dri-devel a few days ago. The idea behind this is to abstract sync_file from any drm driver and let only drm core deal with sync_file. In the next iteration even fence_collection will be gone, so the driver we deal only with struct fence and the fence_collection will be a subclass of fence. Gustavo