"Song, Ruiling" <ruiling.s...@intel.com> writes:
>> -----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-dev@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-...@lists.freedesktop.org
>> >> Cc: Ben Widawsky <b...@bwidawsk.net>; dri-
>> de...@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.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).
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;
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
