On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote: > > > > -----Original Message----- > > From: hoegsberg@xxxxxxxxx [mailto:hoegsberg@xxxxxxxxx] On Behalf Of > > Kristian H?gsberg > > Sent: Monday, December 14, 2015 1:34 PM > > To: Song, Ruiling <ruiling.song@xxxxxxxxx> > > Cc: Winiarski, Michal <michal.winiarski@xxxxxxxxx>; intel- > > gfx@xxxxxxxxxxxxxxxxxxxxx; mesa-dev@xxxxxxxxxxxxxxxxxxxxx; Ben Widawsky > > <ben@xxxxxxxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx > > Subject: Re: [RFC libdrm] intel: Add support for softpin > > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@xxxxxxxxx> > > wrote: > > >> -----Original Message----- > > >> From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On > > Behalf > > >> Of Micha? Winiarski > > >> Sent: Wednesday, September 9, 2015 10:07 PM > > >> To: intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > >> Cc: Ben Widawsky <ben@xxxxxxxxxxxx>; dri- > > devel@xxxxxxxxxxxxxxxxxxxxx; > > >> mesa-dev@xxxxxxxxxxxxxxxxxxxxx > > >> Subject: [RFC libdrm] intel: Add support for softpin > > >> > > >> Softpin allows userspace to take greater control of GPU virtual address > > >> space and eliminates the need of relocations. It can also be used to > > >> mirror addresses between GPU and CPU (shared virtual memory). > > >> Calls to drm_intel_bo_emit_reloc are still required to build the list of > > >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are > > >> created. Self-relocs don't make any sense for softpinned objects and can > > >> indicate a programming errors, thus are forbidden. Softpinned objects > > >> are marked by asterisk in debug dumps. > > >> > > >> Cc: Thomas Daniel <thomas.daniel@xxxxxxxxx> > > >> Cc: Kristian Høgsberg <krh@xxxxxxxxxxxxx> > > >> Cc: Zou Nanhai <nanhai.zou@xxxxxxxxx> > > >> Cc: Michel Thierry <michel.thierry@xxxxxxxxx> > > >> Cc: Ben Widawsky <ben@xxxxxxxxxxxx> > > >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > >> Signed-off-by: Michał Winiarski <michal.winiarski@xxxxxxxxx> > > >> --- > > >> include/drm/i915_drm.h | 4 +- > > >> intel/intel_bufmgr.c | 9 +++ > > >> intel/intel_bufmgr.h | 1 + > > >> intel/intel_bufmgr_gem.c | 176 > > >> ++++++++++++++++++++++++++++++++++++++++------ > > >> intel/intel_bufmgr_priv.h | 7 ++ > > >> 5 files changed, 173 insertions(+), 24 deletions(-) > > > > > > Will anybody help to push the patch to libdrm? Beignet highly depend on > > this to implement ocl2.0 svm. > > > > Is the kernel patch upstream? > > Yes, the kernel patch already merged, see: > http://cgit.freedesktop.org/drm-intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750 > > I find below line of code in libdrm does not match the kernel version. The kernel patch defined as: > "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as (1<<3). Please always regenerate the entire headers from the kernel sources using $ make headers_install Then copy the headers from the kernel's usr/include/drm to libdrm. Never patch i915_drm.h manually. Thanks, Daniel > > Hello Michal, > > Could you help to rebase the patch against: > [PATCH libdrm v4 0/2] 48-bit virtual address support in i915 > I think we need both 48bit & softpin in libdrm. > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h > index ded43b1..2b99fc6 100644 > --- a/include/drm/i915_drm.h > +++ b/include/drm/i915_drm.h > @@ -350,6 +350,7 @@ typedef struct drm_i915_irq_wait { > #define I915_PARAM_REVISION 32 > #define I915_PARAM_SUBSLICE_TOTAL 33 > #define I915_PARAM_EU_TOTAL 34 > +#define I915_PARAM_HAS_EXEC_SOFTPIN 37 > > typedef struct drm_i915_getparam { > int param; > @@ -680,7 +681,8 @@ struct drm_i915_gem_exec_object2 { > #define EXEC_OBJECT_NEEDS_FENCE (1<<0) > #define EXEC_OBJECT_NEEDS_GTT (1<<1) > #define EXEC_OBJECT_WRITE (1<<2) > -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1) > +#define EXEC_OBJECT_PINNED (1<<3) > +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_PINNED<<1) > __u64 flags; > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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
