[Beignet] [Intel-gfx] Preventing zero GPU virtual address allocation

[Daniel Vetter]

On Mon, Mar 16, 2015 at 01:10:28PM -0700, Jesse Barnes wrote:
> On 03/16/2015 01:52 AM, Daniel Vetter wrote:
> > On Mon, Mar 16, 2015 at 02:29:24AM +0000, Song, Ruiling wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> >>> Vetter
> >>> Sent: Saturday, March 14, 2015 1:14 AM
> >>> To: Chris Wilson; Daniel Vetter; Weinehall, David; Zou, Nanhai; Song, Ruiling;
> >>> Vetter, Daniel; intel-gfx at lists.freedesktop.org; Yang, Rong R;
> >>> beignet at lists.freedesktop.org
> >>> Subject: Re: [Beignet] [Intel-gfx] Preventing zero GPU virtual address
> >>> allocation
> >>>
> >>> On Fri, Mar 13, 2015 at 04:58:47PM +0000, Chris Wilson wrote:
> >>>> On Fri, Mar 13, 2015 at 10:27:38AM +0100, Daniel Vetter wrote:
> >>>>> If supporting systems without full ppgtt is a requirement for you
> >>>>> (still wonky on gen8 a bit, so might be a good strategy) then imo
> >>>>> it's the PIN_BIAS idea I've laid out earlier in this thread. That
> >>>>> one will work everywhere. softpin can unexpectedly fail without full
> >>>>> ppgtt if the kernel decides to put something at a given spot, which
> >>>>> imo means we should only expose it on full ppgtt systems.
> >>>>>
> >>>>> And PIN_BIAS should be fairly easy to wire up since the internal
> >>>>> logic is all there already. So "just" needs an execbuf flag, igt
> >>>>> test and appropriate userspace to set that new bit.
> >>>>
> >>>> It doesn't though. To provide the guarantee userspace is asking for
> >>>> (which is that address 0 goes to a special, preferrably inaccessible,
> >>>> page), you have to evict the first N pages in the GGTT. That is just
> >>>> as likely to fail with an execbuffer flag as it would with an execobject flag.
> >>>
> >>> Afaiui userspace only needs the guarantee that NULL is never a valid address.
> >>> Which means it's never a valid address for its own buffer objects. I don't
> >>> think it cares one bit what's actually there, it's not mandatory to fault
> >>> apparently. And faulting is what's not possible.
> >> Yes, This is what exactly what we need, that is make NULL as an invalid address. It's just like C language.
> >> But I have some more comment. The buffer object used in opencl may be allocated in libva/opengl and shared for opencl usage through some opencl extension.
> >> Afaiui, this would implicitly require libva/mesa also avoid zero-address buffer object allocation.
> >> Will libdrm re-bind such kind of shared buffer object to a new graphics virtual address?
> >> So that PIN_BIAS is also effective on the shared buffer, right?
> > 
> > Yeah we'll rebind if needed. We can make this an execbuf or context flag,
> > in either case anything that gets executed by ocl will be moved around if
> > it accidentally ended up at the wrong place. The only exception is if a
> > buffer is pinned already, i.e. if you're doing direct rendering to the
> > frontbuffer. That will give you an EBUSY, but otoh that also shouldn't
> > ever happen really.
> 
> Ruiling, are you working on this or someone from your team, presumably
> based on the patch Chris posted earlier?  The zero page reservation
> certainly seems simpler to me, but the MAP_FIXED approach is a lot more
> flexible, and can be used for other types of debug and usages as well
> (we'll need something like it for OCL pointer sharing for example), so
> seems like a good thing to pursue regardless.

I prefer not to merge fix MAP_FIXED with the justification that ocl will
need the full power of it for buffered svm, without the pieces really
being ready. And I don't think we should block this little fix for current
ocl on the svm work either. Hence why I suggested to just expose the
already existing PIN_BIAS support somehow. That also has the upside of
working without full ppgtt (i.e. on hsw and earlier).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch