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

[Emil Velikov]

On 14 December 2015 at 09:04, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +0000, Song, Ruiling wrote:
>>
>>
>> > -----Original Message-----
>> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: Song, Ruiling <ruiling.song at intel.com>
>> > Cc: krh at bitplanet.net; Winiarski, Michal <michal.winiarski at intel.com>;
>> > mesa-dev at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; Ben
>> > Widawsky <ben at bwidawsk.net>; dri-devel at 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 at gmail.com [mailto:hoegsberg at gmail.com] On Behalf
>> > Of
>> > > > Kristian H?gsberg
>> > > > Sent: Monday, December 14, 2015 1:34 PM
>> > > > To: Song, Ruiling <ruiling.song at intel.com>
>> > > > Cc: Winiarski, Michal <michal.winiarski at intel.com>; intel-
>> > > > gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
>> > Widawsky
>> > > > <ben at bwidawsk.net>; dri-devel at 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 at intel.com>
>> > > > wrote:
>> > > > >> -----Original Message-----
>> > > > >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
>> > > > Behalf
>> > > > >> Of Micha? Winiarski
>> > > > >> Sent: Wednesday, September 9, 2015 10:07 PM
>> > > > >> To: intel-gfx at lists.freedesktop.org
>> > > > >> Cc: Ben Widawsky <ben at bwidawsk.net>; dri-
>> > > > devel at lists.freedesktop.org;
>> > > > >> mesa-dev at 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 at intel.com>
>> > > > >> Cc: Kristian Høgsberg <krh at bitplanet.net>
>> > > > >> Cc: Zou Nanhai <nanhai.zou at intel.com>
>> > > > >> Cc: Michel Thierry <michel.thierry at intel.com>
>> > > > >> Cc: Ben Widawsky <ben at bwidawsk.net>
>> > > > >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>> > > > >> Signed-off-by: Michał Winiarski <michal.winiarski at 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