[Intel-gfx] pin OABUFFER to GGTT

[Chris Wilson]

On Tue, Jul 01, 2014 at 11:40:52PM -0700, Ben Widawsky wrote:
> On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> > On Tue, Jul 01, 2014 at 05:16:30PM +0000, Mateo Lozano, Oscar wrote:
> > > > 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...
> > 
> > Yes. If you need to pin a buffer for a register, then it needs to be
> > handled by the kernel. Especially one that provides information about
> > other users.
> > -Chris
> > 
> 
> I'm unclear why they need the offset. Can it not work like any other
> relocation, except with the requirement that it's in the GGTT?
> 
> I'd also argue that they need to be able to map it (they need the
> contents, which may or may not be mapped). However, I think this is a
> very minor point.
> 
> With the command validator this should be a pretty reasonable thing to
> accomplish. I think we can just give a flag for the reloc that it needs
> to be in the GGTT, and then pass a check to the command scanner that
> only that one offset is allowed, and only for OA.

If the intention was to only measure within a batch and the command
parser ensured that the register was cleared before the end of the
batch, fine. That's not an information leak nor do we keep the hardware
pointing to an unpinned buffer afterwards.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre