On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
>
>
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Monday, December 14, 2015 4:28 PM
> > To: Song, Ruiling <ruiling.s...@intel.com>
> > Cc: k...@bitplanet.net; Winiarski, Michal <michal.winiar...@intel.com>;
> > mesa-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Ben
> > Widawsky <b...@bwidawsk.net>; dri-de...@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: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf
> > Of
> > > > Kristian H?gsberg
> > > > Sent: Monday, December 14, 2015 1:34 PM
> > > > To: Song, Ruiling <ruiling.s...@intel.com>
> > > > Cc: Winiarski, Michal <michal.winiar...@intel.com>; intel-
> > > > g...@lists.freedesktop.org; mesa-...@lists.freedesktop.org; Ben
> > Widawsky
> > > > <b...@bwidawsk.net>; dri-de...@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.s...@intel.com>
> > > > wrote:
> > > > >> -----Original Message-----
> > > > >> From: Intel-gfx [mailto:intel-gfx-boun...@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 <b...@bwidawsk.net>; dri-
> > > > de...@lists.freedesktop.org;
> > > > >> mesa-...@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.dan...@intel.com>
> > > > >> Cc: Kristian Høgsberg <k...@bitplanet.net>
> > > > >> Cc: Zou Nanhai <nanhai....@intel.com>
> > > > >> Cc: Michel Thierry <michel.thie...@intel.com>
> > > > >> Cc: Ben Widawsky <b...@bwidawsk.net>
> > > > >> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> > > > >> Signed-off-by: Michał Winiarski <michal.winiar...@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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
