From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: Fence, timeline and android sync points Date: Thu, 14 Aug 2014 20:47:16 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) by gabe.freedesktop.org (Postfix) with ESMTP id 34E966E0E8 for ; Thu, 14 Aug 2014 11:47:17 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so14506086igb.2 for ; Thu, 14 Aug 2014 11:47:16 -0700 (PDT) In-Reply-To: <20140814181809.GD2000@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 Cc: dri-devel , Ben Skeggs List-Id: dri-devel@lists.freedesktop.org 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. > Sucks because you have a fence object per buffer object and thus overhead grow > with the number of objects. Not even mentioning fence lifetime issue. > > Sucks because sub-buffer allocation is just one of many tricks that can not be > achieved properly and cleanly with implicit sync. > > ... Well I heard all those reasons and I'm well of aware of them. The problem is that with current hardware the kernel needs to know for each buffer how long it needs to be kept around since hw just can't do page faulting. Yeah you can pin them but for an uma design that doesn't go down well with folks. The other problem is that the Linux Desktop I don't seem to care about any more kinda relies on implicit syncing right now, so we better keep that working fairly well. Of course we could dream up a shiny new world where all of the Linux desktop does explicit syncing, but that world doesn't exist right now. I mean really if you want to right away throw implicit syncing overboard that doesn't bode well for the current linux desktop. So I don't understand all the implicit syncing bashing. It's here, and it'll stay for a while longer whether you like it or not ... Of course that doesn't mean we (intel here) won't support explicit syncing too, and I really don't see a conflict here when mixing and matching these two approaches. -Daniel > Having code that work around or alieviate some of this, is in no way a testimony > that it's the best solution. I do believe explicit sync to be superior in use > case it allows way more freedom while the only drawback i see is that you have to > put some trust into userspace. > > So yes implicit sync sucks and it does map to i915 reality as well. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch