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

[Yang, Rong R]

> -----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 Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx