Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757239AbcCXOcU (ORCPT ); Thu, 24 Mar 2016 10:32:20 -0400 Received: from mail-yw0-f171.google.com ([209.85.161.171]:32950 "EHLO mail-yw0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751695AbcCXOcN (ORCPT ); Thu, 24 Mar 2016 10:32:13 -0400 Date: Thu, 24 Mar 2016 11:31:53 -0300 From: Gustavo Padovan To: Maarten Lankhorst Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Stone , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Daniel Vetter , Rob Clark , Greg Hackmann , John Harrison , Gustavo Padovan Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM Message-ID: <20160324143153.GA4781@joana> Mail-Followup-To: Gustavo Padovan , Maarten Lankhorst , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Daniel Stone , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Riley Andrews , Daniel Vetter , Rob Clark , Greg Hackmann , John Harrison , Gustavo Padovan References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3954D.8000308@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F3954D.8000308@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1999 Lines: 61 Hi Maarten, 2016-03-24 Maarten Lankhorst : > Hey, > > Op 23-03-16 om 19:47 schreef Gustavo Padovan: > > From: Gustavo Padovan > > > > 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