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

[Chris Wilson]

On Thu, Aug 21, 2014 at 11:59:04PM -0700, Kenneth Graunke wrote:
> On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote:
> > On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote:
> > > The primary goal of these patches is to introduce what I've started
> > > calling, "prelocations" on Broadwell. A prelocation is like a
> > > relocation, except not. When a GPU client specifies a prelocation, it is
> > > instructing the kernel where in the GPU address the buffer should be
> > > mapped. The mechanic works very similarly to a relocation except it uses
> > > the execbuffer object to obtain the offset, and bind if needed.
> > 
> > You are mixing two APIs. One to preallocate an offset at creation
> > and one to presume relocations during execbuffer. I'd much rather keep
> > the flexible execbuffer approach outlined and first submitted a couple of
> > years ago.
> > 
> > > 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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre