> -----Original Message----- > From: Intel-gfx [mailto:intel-gfx-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of > Jesse Barnes > Sent: Tuesday, March 17, 2015 4:10 AM > To: Daniel Vetter; Song, Ruiling > Cc: Vetter, Daniel; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Yang, Rong R; > beignet@xxxxxxxxxxxxxxxxxxxxx; Weinehall, David > Subject: Re: [Beignet] Preventing zero GPU virtual address allocation > > 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@xxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxxx; > >>> Yang, Rong R; beignet@xxxxxxxxxxxxxxxxxxxxx > >>> Subject: Re: [Beignet] 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. > Hi Jesse, MAP_FIXED cannot solve this issue. You may see my previous comments for this topic, There could be many components in on single process, Beignet cannot be guaranteed to be the first one who has allocated address 0. Thanks Zou Nanhai > Thanks, > Jesse > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
