On 14 December 2015 at 09:04, Daniel Vetter <dan...@ffwll.ch> wrote: > 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-dev@lists.freedesktop.org; intel-...@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-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). >> > >> > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
