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@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. 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
