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