From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Mateo Lozano, Oscar" <oscar.mateo@intel.com>
Subject: Re: pin OABUFFER to GGTT
Date: Tue, 1 Jul 2014 17:16:30 +0000
Message-ID: <92648605EABDA246B775AAB04C95A7A3137EB5E3@IRSMSX103.ger.corp.intel.com>
References: <92648605EABDA246B775AAB04C95A7A3137EB4F3@IRSMSX103.ger.corp.intel.com>
 <20140701163017.GA7371@nuc-i3427.alporthouse.com>
 <92648605EABDA246B775AAB04C95A7A3137EB523@IRSMSX103.ger.corp.intel.com>
 <20140701165149.GB7371@nuc-i3427.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by gabe.freedesktop.org (Postfix) with ESMTP id BFF696E46A
 for <Intel-gfx@lists.freedesktop.org>; Tue,  1 Jul 2014 10:17:09 -0700 (PDT)
Content-Language: en-US
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Intel-gfx@lists.freedesktop.org" <Intel-gfx@lists.freedesktop.org>, "Madajczak, Tomasz" <Tomasz.Madajczak@intel.com>
List-Id: intel-gfx@lists.freedesktop.org

> -----Original Message-----
> From: Mateo Lozano, Oscar
> Sent: Tuesday, July 01, 2014 6:14 PM
> To: 'Chris Wilson'
> Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz; Rutkowski, Adam J;
> Jesse Barnes (jbarnes@virtuousgeek.org)
> Subject: RE: [Intel-gfx] pin OABUFFER to GGTT
> =

> > -----Original Message-----
> > From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> > Sent: Tuesday, July 01, 2014 5:52 PM
> > To: Mateo Lozano, Oscar
> > Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz; Rutkowski,
> > Adam J; Jesse Barnes (jbarnes@virtuousgeek.org)
> > Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
> >
> > On Tue, Jul 01, 2014 at 04:34:48PM +0000, Mateo Lozano, Oscar wrote:
> > > > -----Original Message-----
> > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk]
> > > > Sent: Tuesday, July 01, 2014 5:30 PM
> > > > To: Mateo Lozano, Oscar
> > > > Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz
> > > > Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
> > > >
> > > > On Tue, Jul 01, 2014 at 04:24:56PM +0000, Mateo Lozano, Oscar
> wrote:
> > > > > Submitting again (this time copying the mailing list correctly):
> > > > >
> > > > > The bo_pin ioctl has been discarded in GEN6+ with this patch:
> > > > >
> > > > > =A0=A0=A0 drm/i915: Reject the pin ioctl on gen6+
> > > > >
> > > > > =A0=A0=A0=A0Especially with ppgtt this kinda stopped making sense=
. And
> > > > > if we
> > > > > =A0=A0=A0 indeed need this to hack around an issue, we need somet=
hing
> > > > > that also
> > > > > =A0=A0=A0 works for non-root.
> > > > >
> > > > > =A0=A0=A0=A0Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
> > > > >
> > > > > The thing is, the performance team used this call to pin the
> > > > > OABUFFER to
> > > > GGTT and then mapping it to userspace. This OABUFFER cannot be in
> > > > PPGTT
> > > > because: "When each context has its own Per Process GTT, this
> > > > field should be always set to GGTT." (BSpec dixit).
> > > > >
> > > > > Can we re-enable it? or should we find an alternative for this ca=
se?
> > > >
> > > > EXEC_OBJECT_NEEDS_GTT?
> > > > -Chris
> > >
> > > The object (AFAICT, please Tomasz correct me if I am wrong) is not
> > > really
> > used inside any batchbuffer.
> >
> > Then what's the issue? If you only use it as via a global gtt mapping
> > it only exists in the ggtt.
> =

> The issue is they need:
> =

> A) A buffer object.
> B) Bound to GGTT.
> C) That userspace knows the GGTT offset of, so that they can program
> OABUFFER with it.
> D) That userspace can map so that they can read the reported counters.
> =

> They used to create a bo, call bo_pin on it, use args->offset to program
> OABUFFER (via MI_LOAD_REGISTER_IMM, I imagine), map it and read the
> counter values. They cannot do this anymore.

The answer might be that all of this needs to be done by the kernel itself,=
 but then we need to provide an interface to userspace...