Kristian Høgsberg <hoegsberg@xxxxxxxxx> writes: > "Song, Ruiling" <ruiling.song@xxxxxxxxx> writes: > >>> -----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: [Intel-gfx] [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: [Intel-gfx] [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). > > I have the two 48 bit patches merge here. I'll pull in Michał's patch, > update the kernel header and then push it all. All pushed now. Kristian >> Hello Michal, >> >> Could you help to rebase the patch against: >> [Intel-gfx] [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; >> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
