> -----Original Message----- > From: Daniel, Thomas > Sent: Wednesday, October 21, 2015 23:11 > To: Daniel Vetter > Cc: Chris Wilson; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Belgaumkar, Vinay; Yang, > Rong R > Subject: RE: [PATCH 3/3] drm/i915: Add soft-pinning API for > execbuffer > > > -----Original Message----- > > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of > > Daniel Vetter > > Sent: Wednesday, October 21, 2015 4:08 PM > > To: Daniel, Thomas > > Cc: Chris Wilson; intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [PATCH 3/3] drm/i915: Add soft-pinning API > > for execbuffer > > > > On Tue, Oct 06, 2015 at 01:59:12PM +0000, Daniel, Thomas wrote: > > > > -----Original Message----- > > > > From: Chris Wilson [mailto:chris@xxxxxxxxxxxxxxxxxx] > > > > Sent: Tuesday, October 6, 2015 11:53 AM > > > > To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > > Cc: Chris Wilson; Daniel, Thomas > > > > Subject: [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer > > > > > > > > Userspace can pass in an offset that it presumes the object is > > > > located at. The kernel will then do its utmost to fit the object > > > > into that location. The assumption is that userspace is handling > > > > its own object locations (for example along with full-ppgtt) and > > > > that the kernel will rarely have to make space for the user's requests. > > > > > > > > v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle > > > > ordinary and fixed objects within the same batch > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Cc: "Daniel, Thomas" <thomas.daniel@xxxxxxxxx> > > > > > > This didn't apply cleanly to my tree pulled today (after patches 1 > > > and 2 of this > > series). > > > Are you going to post a rebase? > > > > It's a really trivial conflict in the uapi flag allocation. Happens > > all the time with interface extensions. > > > > What I'm looking for here is the userspace for this new interface. And > > the testcases. > Hm I thought the beignet guys had already posted. > Vinay has written i-g-t for this Beignet svm patch haven't post, because the beignet's svm patch only work on i386 linux now, the x86_64 svm depends on 48bits pointer support in Beignet compiler's backend. If the i386 svm patch is worthy for this patch, I will send it out. > > > -Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
