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

[Chris Wilson]

On Wed, Jul 08, 2015 at 03:04:45PM +0000, Daniel, Thomas wrote:
> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Saturday, July 4, 2015 1:24 PM
> > To: Kristian Høgsberg
> > Cc: Daniel, Thomas; Belgaumkar, Vinay; intel-gfx at lists.freedesktop.org; Michal
> > Winiarsky; Goel, Akash
> > Subject: Re: [Intel-gfx] [PATCH v4] drm/i915: Add soft-pinning API for execbuffer
> > 
> > On Fri, Jul 03, 2015 at 10:29:44PM -0700, Kristian Høgsberg wrote:
> > > On Tue, Jun 30, 2015 at 7:13 AM, Thomas Daniel <thomas.daniel at intel.com>
> > wrote:
> > > > From: Chris Wilson <chris at chris-wilson.co.uk>
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > >
> > > > v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
> > > > Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
> > > > (Not published externally)
> > > >
> > > > v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
> > > > to allow eviction of soft-pinned objects when another soft-pinned object
> > used
> > > > by a subsequent execbuffer overlaps reported by Michal Winiarski.
> > > > (Not published externally)
> > > >
> > > > v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
> > > > pinned first after an address conflict happens to avoid repeated conflicts in
> > > > rare cases (Suggested by Chris Wilson).  Expanded comment on
> > > > drm_i915_gem_exec_object2.offset to cover this new API.
> > 
> > Note this patch is outdated compared to the one I have in my tree. There
> > are also requirements to improve drm_mm_reserve_node().
> What requirements are these?

I switched execbuffer to try reusing the last address by default (i.e.
softpin everything) and the linear walk in reserve_node and
evict_for_vma were major bottlenecks. Adding an interval-tree to drm_mm
fixes the issue but also requires rewriting evict_for_vma. Plus using it
by default highlighted a few errors in the failure handling.

Also don't forget that softpinning requires us to be able to reuse the
vm for all rings, i.e. we need the API fix to allow user contexts for
rings other than RCS.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre