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.vet...@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; >>> beig...@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.
Oh and we may need to re-introduce the ppgtt zero page reservation anyway due to bugs, but that's another topic... _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
