From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: Fence, timeline and android sync points Date: Thu, 14 Aug 2014 21:40:08 +0200 Message-ID: <53ED1098.906@canonical.com> References: <20140812221340.GB5746@gmail.com> <20140813082822.GO10500@phenom.ffwll.local> <20140813133602.GA2666@gmail.com> <20140813155420.GG10500@phenom.ffwll.local> <20140813170719.GD2666@gmail.com> <20140814090834.GK10500@phenom.ffwll.local> <20140814142329.GC2000@gmail.com> <20140814155551.GY10500@phenom.ffwll.local> <20140814181809.GD2000@gmail.com> <20140814191505.GH2000@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mblankhorst.nl (mblankhorst.nl [141.105.120.124]) by gabe.freedesktop.org (Postfix) with ESMTP id CE1276E73D for ; Thu, 14 Aug 2014 12:40:10 -0700 (PDT) In-Reply-To: <20140814191505.GH2000@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jerome Glisse , Daniel Vetter Cc: dri-devel , Ben Skeggs List-Id: dri-devel@lists.freedesktop.org On 14-08-14 21:15, Jerome Glisse wrote: > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote: >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote: >>> Sucks because you can not do weird synchronization like one i depicted in another >>> mail in this thread and for as long as cmdbuf_ioctl do not give you fence|syncpt >>> you can not such thing cleanly in non hackish way. >> >> Actually i915 can soon will do that that. > > So you will return fence|syncpoint with each cmdbuf_ioctl ? It might, soon. There have been patches on the ml about it. It can create a userspace android fence backed by a kernel dma fence. And it will be created like any other userspace android fence. ;-) Yet even with that, it will continue to support the implicit sync model since they're not mutually exclusive. I also fail to understand why you think a fence should be associated with a buffer object. It's the other way around. TTM currently requires buffer objects to be fenced off to protect against eviction. reservation_object is used for this, and by sharing the reservation_object pointer with a dma-buf you get cross-device synchronization. It has a bunch of helpers to make common operations easy, see include/linux/reservation.h and drivers/dma-buf/reservation.c It also allows multiple readers simultaneously across any number of devices. I intend to use this in nouveau. But there's no requirement to use reservation_object's apart from that's how ttm currently works, and for implicit syncing in dma-buf. If you don't need either go crazy with fence and write your own mechanism on top of fence. Although with android sync and TTM I think I handled all common usecases. ~Maarten