[Intel-gfx] pin OABUFFER to GGTT

[Mateo Lozano, Oscar]

> -----Original Message-----
> From: Mateo Lozano, Oscar
> Sent: Tuesday, July 01, 2014 6:14 PM
> To: 'Chris Wilson'
> Cc: Intel-gfx at lists.freedesktop.org; Madajczak, Tomasz; Rutkowski, Adam J;
> Jesse Barnes (jbarnes at virtuousgeek.org)
> Subject: RE: [Intel-gfx] pin OABUFFER to GGTT
> 
> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Tuesday, July 01, 2014 5:52 PM
> > To: Mateo Lozano, Oscar
> > Cc: Intel-gfx at lists.freedesktop.org; Madajczak, Tomasz; Rutkowski,
> > Adam J; Jesse Barnes (jbarnes at 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 at chris-wilson.co.uk]
> > > > Sent: Tuesday, July 01, 2014 5:30 PM
> > > > To: Mateo Lozano, Oscar
> > > > Cc: Intel-gfx at 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:
> > > > >
> > > > >     drm/i915: Reject the pin ioctl on gen6+
> > > > >
> > > > >     Especially with ppgtt this kinda stopped making sense. And
> > > > > if we
> > > > >     indeed need this to hack around an issue, we need something
> > > > > that also
> > > > >     works for non-root.
> > > > >
> > > > >     Signed-off-by: Daniel Vetter daniel.vetter at 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 case?
> > > >
> > > > 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...