RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----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).

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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux