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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
