[Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

[Daniel, Thomas]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, October 21, 2015 4:08 PM
> To: Daniel, Thomas
> Cc: Chris Wilson; intel-gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [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 at chris-wilson.co.uk]
> > > Sent: Tuesday, October 6, 2015 11:53 AM
> > > To: intel-gfx at lists.freedesktop.org
> > > 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 at chris-wilson.co.uk>
> > > Cc: "Daniel, Thomas" <thomas.daniel at intel.com>
> >
> > 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

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch