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

Daniel, Thomas thomas.daniel at intel.com
Wed Nov 4 02:46:36 PST 2015


> -----Original Message-----
> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf Of
> Yang, Rong R
> Sent: Wednesday, November 4, 2015 10:32 AM
> To: Chris Wilson; Winiarski, Michal
> Cc: intel-gfx at lists.freedesktop.org; Kristian H?gsberg; dri-
> devel at lists.freedesktop.org; Goel, Akash; mesa-dev at lists.freedesktop.org;
> Belgaumkar, Vinay
> Subject: Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for
> execbuffer
> 
> 
> 
> > -----Original Message-----
> > From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf
> > Of Chris Wilson
> > Sent: Wednesday, September 9, 2015 22:25
> > To: Winiarski, Michal
> > Cc: intel-gfx at lists.freedesktop.org; Kristian Høgsberg; dri-
> > devel at lists.freedesktop.org; Goel, Akash; Belgaumkar, Vinay; mesa-
> > dev at lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add soft-pinning API for
> > execbuffer
> >
> > On Wed, Sep 09, 2015 at 04:07:09PM +0200, Michał Winiarski 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.
> > >
> > > 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.
> > >
> > > v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this
> > > capability (Kristian). Added check for multiple pinnings on eviction
> > > (Akash). Made sure buffers are not considered misplaced without the
> > > user specifying EXEC_OBJECT_SUPPORTS_48BBADDRESS.  User must
> > assume
> > > responsibility for any addressing workarounds.  Updated object2.offset
> > > field comment again to clarify NO_RELOC case (Chris).  checkpatch cleanup.
> > >
> > > v6: Rebase on top of current nightly. Dropped any references to
> > > EXEC_OBJECT_SUPPORTS_48BBADDRESS since those don't exist in
> > upstream
> > > yet, and are not a dependency.
> > >
> > > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Akash Goel <akash.goel at intel.com>
> > > Cc: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
> > > Cc: Michal Winiarski <michal.winiarski at intel.com>
> > > Cc: Zou Nanhai <nanhai.zou at intel.com>
> > > Cc: Kristian Høgsberg <hoegsberg at gmail.com>
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Signed-off-by: Thomas Daniel <thomas.daniel at intel.com>
> > > Signed-off-by: Michał Winiarski <michal.winiarski at intel.com>
> >
> > Again, the precursors are not included in this series or upstream, so NAK.
> > -Chris
> I have post a beignet's OpenCL2.0 SVM patch based on this patch set. It works
> well on i386 system.
> Can you  review this patchset again? thanks.
Chris posted a new version which we want to use instead.  Akash has posted a comment on it already.
http://patchwork.freedesktop.org/patch/61122/

Thomas.


More information about the Intel-gfx mailing list