From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: pin OABUFFER to GGTT Date: Thu, 3 Jul 2014 13:45:29 -0700 Message-ID: <20140703204529.GA16708@bwidawsk.net> References: <20140701195427.GA11155@nuc-i3427.alporthouse.com> <20140702064052.GA2723@bwidawsk.net> <20140702065559.GA3015@nuc-i3427.alporthouse.com> <92648605EABDA246B775AAB04C95A7A3137EB7D6@IRSMSX103.ger.corp.intel.com> <20140702104916.GB26852@strange.amr.corp.intel.com> <092ACDCAA6E4654AAFE75E8A5E9EAB7B2CBE6F1D@IRSMSX102.ger.corp.intel.com> <20140703071732.GA2262@strange.amr.corp.intel.com> <20140703171047.GA976@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 204006E766 for ; Thu, 3 Jul 2014 13:45:35 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140703171047.GA976@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Damien Lespiau Cc: "Intel-gfx@lists.freedesktop.org" , "Madajczak, Tomasz" , "Wilson, Chris" List-Id: intel-gfx@lists.freedesktop.org On Thu, Jul 03, 2014 at 10:10:48AM -0700, Ben Widawsky wrote: > On Thu, Jul 03, 2014 at 08:17:32AM +0100, Damien Lespiau wrote: > > On Wed, Jul 02, 2014 at 02:19:42PM +0100, Rutkowski, Adam J wrote: > > > Having said all this, how about restoring the pin_ioctl? At least for > > > some time? We do have a use case and moving to other - better - > > > solution would take time. I think backward compatibility is something > > > that you take into consideration as well. > > > > So, I just sent a patch reverting the change. Daniel will have an > > opinion about this I'm sure, being the original author. Let see what > > happens when he's back from holidays. > > > > Cheers, > > > > -- > > Damien > > Just a note for a future ppgtt people - this adds another way to get > multiple VMAs for a single BO. To this point, it had only been flink, > and dmabuf. IIRC there are few unhandled corner cases for this. Also > note that if the BO is still referenced within a batch, we need the flag > to tell us it needs global binding. > > FWIW, I remain in favor of the relocation idea unless someone already > expressed why we need multiple processes to have the relocation info. > I just realized there isn't really a good way to make the buffer persist at the same offset if we use the relocation method. So I take back the statement that it's a good idea. -- Ben Widawsky, Intel Open Source Technology Center