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