On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxxxxxxxx> 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. Well I admit to not having read the patches over the terrible wifi here, but I presumed Ben's patches did implement softpin. I guess I've made a mess of all of this now. In any case I still want to see relative improvements over what we have since the prelocated stuff looks like a gen8 oneshot. And we still can't do relocation-less execbuf because the gpu can't fault, so I'm not sure at all whether this is actually useful for opencl 2.0. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
