[Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)

[Chris Wilson]

On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote:
> On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> > > If a GPU
> >> > > client uses only prelocations, the relocation process can be entirely
> >> > > skipped. This sounds like a big win initially,
> >> >
> >> > Close to zero if the client uses existing interfaces.
> >> > -Chris
> >>
> >> Chris,
> >>
> >> I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver.  It wasn't invasive at all---I was surprised.
> >
> > Indeed, you could do everything inside libdrm with the code I posted 2
> > years ago.
> 
> I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need
> to walk all the reloc tables (if nothing moved) because userspace
> didn't go insane and reuse reloc trees. So you'd need to implement a
> flag + a libdrm function to set that (iirc mesa has been non-stupid
> since years). And yeah I kinda expect any new reloc-less thing to get
> benchmarked against an implementation using that, since the 48bit
> specific thing proposed looks like a fairly short-lived stop-gap, and
> since the current no-reloc we already have would work everywhere. And
> yeah I've been poking people to look at this for years. too.

Here, I was referring to soft-pinning. The API here is essentially
comprised of two parts:

1: a pin into the vm upon creation
2: implicit no-relocation upon execbuffer

By making those two steps independent, the API as I see is, is more
flexible and powerful.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre