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

[Song, Ruiling]

> -----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?

Thanks!
Ruiling
> I guess the standard is like normal C: If you access a NULL pointer, anything
> can happen (including garbage on the frontbuffer), the only guarantee you
> need to make is that NULL is never a valid address. At least if no one plays
> tricks ;-) -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch