[Intel-gfx] pin OABUFFER to GGTT

[Chris Wilson]

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.

> Also:
> 
> 		if (exec[i].flags & EXEC_OBJECT_NEEDS_GTT &&
> 		    USES_FULL_PPGTT(vm->dev)) {
> 			ret = -EINVAL;
> 			goto err;
> 		}
> 

Yeah, that's just full-ppgtt not quite being ready yet.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre