Re: [Beignet] Preventing zero GPU virtual address allocation

From: "Song, Ruiling" <ruiling.song@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	"Weinehall, David" <david.weinehall@intel.com>,
	"Zou, Nanhai" <nanhai.zou@intel.com>,
	"Vetter, Daniel" <daniel.vetter@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Yang, Rong R" <rong.r.yang@intel.com>,
	"beignet@lists.freedesktop.org" <beignet@lists.freedesktop.org>
Subject: Re: [Beignet] Preventing zero GPU virtual address allocation
Date: Mon, 16 Mar 2015 02:29:24 +0000	[thread overview]
Message-ID: <148B1B7A67D1C24B9EF0BE42EA4977062B7F5DFE@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <20150313171339.GL3800@phenom.ffwll.local>


> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@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@lists.freedesktop.org; Yang, Rong R;
> beignet@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx