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

Submitted by Song, Ruiling on Dec. 14, 2015, 7:24 a.m.

Details

Message ID 148B1B7A67D1C24B9EF0BE42EA4977064E408E32@shsmsx102.ccr.corp.intel.com
State New
Series "intel: Add support for softpin"
Headers show

Commit Message

Song, Ruiling Dec. 14, 2015, 7:24 a.m.
> -----Original Message-----

> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of

> Kristian H?gsberg

> Sent: Monday, December 14, 2015 1:34 PM

> To: Song, Ruiling <ruiling.song@intel.com>

> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-

> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky

> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org

> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

> 

> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>

> wrote:

> >> -----Original Message-----

> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On

> Behalf

> >> Of Micha? Winiarski

> >> Sent: Wednesday, September 9, 2015 10:07 PM

> >> To: intel-gfx@lists.freedesktop.org

> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-

> devel@lists.freedesktop.org;

> >> mesa-dev@lists.freedesktop.org

> >> 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@intel.com>

> >> Cc: Kristian Høgsberg <krh@bitplanet.net>

> >> Cc: Zou Nanhai <nanhai.zou@intel.com>

> >> Cc: Michel Thierry <michel.thierry@intel.com>

> >> Cc: Ben Widawsky <ben@bwidawsk.net>

> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>

> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>

> >> ---

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

Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Patch hide | download patch | download mbox

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;
 
_______________________________________________

Comments

Daniel Vetter Dec. 14, 2015, 8:28 a.m.
On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
> 
> 
> > -----Original Message-----
> > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
> > Kristian H?gsberg
> > Sent: Monday, December 14, 2015 1:34 PM
> > To: Song, Ruiling <ruiling.song@intel.com>
> > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
> > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> > wrote:
> > >> -----Original Message-----
> > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> > Behalf
> > >> Of Micha? Winiarski
> > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > >> To: intel-gfx@lists.freedesktop.org
> > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> > devel@lists.freedesktop.org;
> > >> mesa-dev@lists.freedesktop.org
> > >> 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@intel.com>
> > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> > >> Cc: Michel Thierry <michel.thierry@intel.com>
> > >> Cc: Ben Widawsky <ben@bwidawsk.net>
> > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > >> ---
> > >>  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:
> [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;
>  
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Song, Ruiling Dec. 14, 2015, 8:41 a.m.
> -----Original Message-----

> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel

> Vetter

> Sent: Monday, December 14, 2015 4:28 PM

> To: Song, Ruiling <ruiling.song@intel.com>

> Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;

> mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben

> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org

> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

> 

> On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:

> >

> >

> > > -----Original Message-----

> > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf

> Of

> > > Kristian H?gsberg

> > > Sent: Monday, December 14, 2015 1:34 PM

> > > To: Song, Ruiling <ruiling.song@intel.com>

> > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-

> > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben

> Widawsky

> > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org

> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

> > >

> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>

> > > wrote:

> > > >> -----Original Message-----

> > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On

> > > Behalf

> > > >> Of Micha? Winiarski

> > > >> Sent: Wednesday, September 9, 2015 10:07 PM

> > > >> To: intel-gfx@lists.freedesktop.org

> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-

> > > devel@lists.freedesktop.org;

> > > >> mesa-dev@lists.freedesktop.org

> > > >> 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@intel.com>

> > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>

> > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>

> > > >> Cc: Michel Thierry <michel.thierry@intel.com>

> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>

> > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>

> > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>

> > > >> ---

> > > >>  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 for the info. But the problem is libdrm still tracks such kind of header files.
Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

Thanks!
Ruiling
 
> Thanks, Daniel

> 

> >

> > 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;

> >

> > _______________________________________________

> > Intel-gfx mailing list

> > Intel-gfx@lists.freedesktop.org

> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

> 

> --

> Daniel Vetter

> Software Engineer, Intel Corporation

> http://blog.ffwll.ch
Daniel Vetter Dec. 14, 2015, 9:04 a.m.
On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
> 
> 
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling <ruiling.song@intel.com>
> > Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
> > mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
> > Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > 
> > On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
> > Of
> > > > Kristian H?gsberg
> > > > Sent: Monday, December 14, 2015 1:34 PM
> > > > To: Song, Ruiling <ruiling.song@intel.com>
> > > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
> > > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
> > Widawsky
> > > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> > > >
> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
> > > > wrote:
> > > > >> -----Original Message-----
> > > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
> > > > Behalf
> > > > >> Of Micha? Winiarski
> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
> > > > >> To: intel-gfx@lists.freedesktop.org
> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
> > > > devel@lists.freedesktop.org;
> > > > >> mesa-dev@lists.freedesktop.org
> > > > >> 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@intel.com>
> > > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
> > > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
> > > > >> Cc: Michel Thierry <michel.thierry@intel.com>
> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
> > > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> > > > >> ---
> > > > >>  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 for the info. But the problem is libdrm still tracks such kind of header files.
> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

All other kernel headers are extracted from the kernel directly, but
generally those packages only get update when a new kernel comes out.
Usually it's called linux-headers or similar. And only updating headers
when the release is out is _way_ too slow for drm/gfx. That's why we have
drm headers in libdrm.

But yeah we should document this, maybe even script it. Perhaps even just
upgrade headers automatically as soon as the upstream drm-next branch
changes.
-Daniel

> 
> Thanks!
> Ruiling
>  
> > Thanks, Daniel
> > 
> > >
> > > 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;
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
Emil Velikov Dec. 14, 2015, 11:45 a.m.
On 14 December 2015 at 09:04, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
>>
>>
>> > -----Original Message-----
>> > From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: Song, Ruiling <ruiling.song@intel.com>
>> > Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
>> > mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
>> > Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> >
>> > On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
>> > Of
>> > > > Kristian H?gsberg
>> > > > Sent: Monday, December 14, 2015 1:34 PM
>> > > > To: Song, Ruiling <ruiling.song@intel.com>
>> > > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> > > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> > Widawsky
>> > > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > > >
>> > > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> > > > wrote:
>> > > > >> -----Original Message-----
>> > > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> > > > Behalf
>> > > > >> Of Micha? Winiarski
>> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > > >> To: intel-gfx@lists.freedesktop.org
>> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> > > > devel@lists.freedesktop.org;
>> > > > >> mesa-dev@lists.freedesktop.org
>> > > > >> 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@intel.com>
>> > > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> > > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> > > > >> Cc: Michel Thierry <michel.thierry@intel.com>
>> > > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> > > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> > > > >> ---
>> > > > >>  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 for the info. But the problem is libdrm still tracks such kind of header files.
>> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?
>
> All other kernel headers are extracted from the kernel directly, but
> generally those packages only get update when a new kernel comes out.
> Usually it's called linux-headers or similar. And only updating headers
> when the release is out is _way_ too slow for drm/gfx. That's why we have
> drm headers in libdrm.
>
That plus hysterical raisins, from when drm was part of userspace ;-)

> But yeah we should document this, maybe even script it. Perhaps even just
> upgrade headers automatically as soon as the upstream drm-next branch
> changes.
I'm all for tweaking the make target, although automating to the point
of zero developer interaction might not be ideal. Plus we do have the
occasional revert in -next and even -rcX :-\

-Emil
Kristian Høgsberg Dec. 14, 2015, 6:25 p.m.
"Song, Ruiling" <ruiling.song@intel.com> writes:

>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, December 14, 2015 4:28 PM
>> To: Song, Ruiling <ruiling.song@intel.com>
>> Cc: krh@bitplanet.net; Winiarski, Michal <michal.winiarski@intel.com>;
>> mesa-dev@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
>> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Mon, Dec 14, 2015 at 07:24:29AM +0000, Song, Ruiling wrote:
>> >
>> >
>> > > -----Original Message-----
>> > > From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf
>> Of
>> > > Kristian H?gsberg
>> > > Sent: Monday, December 14, 2015 1:34 PM
>> > > To: Song, Ruiling <ruiling.song@intel.com>
>> > > Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> > > gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben
>> Widawsky
>> > > <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> > > Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> > >
>> > > On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> > > wrote:
>> > > >> -----Original Message-----
>> > > >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> > > Behalf
>> > > >> Of Micha? Winiarski
>> > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > >> To: intel-gfx@lists.freedesktop.org
>> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> > > devel@lists.freedesktop.org;
>> > > >> mesa-dev@lists.freedesktop.org
>> > > >> 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@intel.com>
>> > > >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> > > >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> > > >> Cc: Michel Thierry <michel.thierry@intel.com>
>> > > >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> > > >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > > >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> > > >> ---
>> > > >>  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 for the info. But the problem is libdrm still tracks such kind of header files.
> Should this kind of header file be removed from libdrm? Or any document in libdrm to make this explicit?

The motivation is that compiling libdrm should be independent of
kernel headers on the system. You could probably get away with requiring
some recent enough linux-headers pkg or something, but in the end this
seemed more pragmatic.

Kristian

> Thanks!
> Ruiling
>  
>> Thanks, Daniel
>> 
>> >
>> > 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;
>> >
>> > _______________________________________________
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
Kristian Høgsberg Dec. 14, 2015, 6:36 p.m.
"Song, Ruiling" <ruiling.song@intel.com> writes:

>> -----Original Message-----
>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
>> Kristian H?gsberg
>> Sent: Monday, December 14, 2015 1:34 PM
>> To: Song, Ruiling <ruiling.song@intel.com>
>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>> 
>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>> wrote:
>> >> -----Original Message-----
>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>> Behalf
>> >> Of Micha? Winiarski
>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>> >> To: intel-gfx@lists.freedesktop.org
>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>> devel@lists.freedesktop.org;
>> >> mesa-dev@lists.freedesktop.org
>> >> 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@intel.com>
>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>> >> Cc: Michel Thierry <michel.thierry@intel.com>
>> >> Cc: Ben Widawsky <ben@bwidawsk.net>
>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>> >> ---
>> >>  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.

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;
>
Kristian Høgsberg Dec. 14, 2015, 8:09 p.m.
Kristian Høgsberg <hoegsberg@gmail.com> writes:

> "Song, Ruiling" <ruiling.song@intel.com> writes:
>
>>> -----Original Message-----
>>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf Of
>>> Kristian H?gsberg
>>> Sent: Monday, December 14, 2015 1:34 PM
>>> To: Song, Ruiling <ruiling.song@intel.com>
>>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-
>>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben Widawsky
>>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org
>>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
>>> 
>>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>
>>> wrote:
>>> >> -----Original Message-----
>>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On
>>> Behalf
>>> >> Of Micha? Winiarski
>>> >> Sent: Wednesday, September 9, 2015 10:07 PM
>>> >> To: intel-gfx@lists.freedesktop.org
>>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-
>>> devel@lists.freedesktop.org;
>>> >> mesa-dev@lists.freedesktop.org
>>> >> 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@intel.com>
>>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>
>>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>
>>> >> Cc: Michel Thierry <michel.thierry@intel.com>
>>> >> Cc: Ben Widawsky <ben@bwidawsk.net>
>>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
>>> >> ---
>>> >>  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;
>>
Song, Ruiling Dec. 16, 2015, 3:29 a.m.
> -----Original Message-----

> From: Kristian Høgsberg [mailto:hoegsberg@gmail.com]

> Sent: Tuesday, December 15, 2015 4:09 AM

> To: Song, Ruiling <ruiling.song@intel.com>; krh@bitplanet.net; Winiarski,

> Michal <michal.winiarski@intel.com>

> Cc: intel-gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben

> Widawsky <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org; Yang,

> Rong R <rong.r.yang@intel.com>

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

> 

> Kristian Høgsberg <hoegsberg@gmail.com> writes:

> 

> > "Song, Ruiling" <ruiling.song@intel.com> writes:

> >

> >>> -----Original Message-----

> >>> From: hoegsberg@gmail.com [mailto:hoegsberg@gmail.com] On Behalf

> Of

> >>> Kristian H?gsberg

> >>> Sent: Monday, December 14, 2015 1:34 PM

> >>> To: Song, Ruiling <ruiling.song@intel.com>

> >>> Cc: Winiarski, Michal <michal.winiarski@intel.com>; intel-

> >>> gfx@lists.freedesktop.org; mesa-dev@lists.freedesktop.org; Ben

> Widawsky

> >>> <ben@bwidawsk.net>; dri-devel@lists.freedesktop.org

> >>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin

> >>>

> >>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling <ruiling.song@intel.com>

> >>> wrote:

> >>> >> -----Original Message-----

> >>> >> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On

> >>> Behalf

> >>> >> Of Micha? Winiarski

> >>> >> Sent: Wednesday, September 9, 2015 10:07 PM

> >>> >> To: intel-gfx@lists.freedesktop.org

> >>> >> Cc: Ben Widawsky <ben@bwidawsk.net>; dri-

> >>> devel@lists.freedesktop.org;

> >>> >> mesa-dev@lists.freedesktop.org

> >>> >> 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@intel.com>

> >>> >> Cc: Kristian Høgsberg <krh@bitplanet.net>

> >>> >> Cc: Zou Nanhai <nanhai.zou@intel.com>

> >>> >> Cc: Michel Thierry <michel.thierry@intel.com>

> >>> >> Cc: Ben Widawsky <ben@bwidawsk.net>

> >>> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>

> >>> >> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>

> >>> >> ---

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


Thanks. We have tried some basic OpenCL tests. Both patches work!
I have another question, does KMD allow soft-pin a bo at zero address?
I have tried to pin a bo with the size of 64KB at zero address in Beignet. It can succeed.
But I met some random failure with bo_exec() returning -EINVAL.
I am trying to figure out why. So I want to confirm is it allowed by KMD?

Thanks!
Ruiling