On Fri, Mar 13, 2015 at 11:10:56AM +0200, David Weinehall wrote: > On 2015-03-09 14:02, Chris Wilson wrote: > >On Mon, Mar 09, 2015 at 02:34:46AM +0000, Zou, Nanhai wrote: > >>We don't need MAP_FIXED, we just want to avoid address 0 to be allocated. > >> > >>Though I think using MAP_FIXED is overkill, will bring much unnecessary complexity on both kernel and beignet side. > >>I don't mind if people can provide stable MAP_FIXED patches to resolve this problem a few months or years later. > >> > >>At that time, kernel driver can revert the reserve page 0 patch. > >>Before that reserve page 0 can benefit all the Beignet user without breaking anything. > > > >The point is that is becomes ABI. So no the kernel can't just revert it. > >There is nothing special about address 0 in ether GTT or virtual memory. > >If you require a special object allocated at address 0, allocate a > >special object at address 0. > > I've explained the ABI issue in a separate e-mail discussion, and I > believe that they now fully understand what you meant. > > That said, their main chain of reasoning makes some sense -- there is a > race condition if we rely on using MAP_FIXED, at least on systems that > do not support ppgtt. Ending up in a situation where opencl > applications work on other hw, but fails when run on an i915-system > would, at least in my opinion, not be ideal, no matter if it's due > to an unfortunate design. > > *If* a MAP_FIXED solution is decided upon, how can userland be sure > that the GTT page mapped to 0 is indeed usable as the NULL pointer? > ON a PPGTT system that would be easy enough -- it's per process, so > we'll be the only process allocating a page at 0, but if allocations > use a global address space that won't be possible to guarantee. It's simple, userspace has no control over allocation of the GGTT. Espcially something like address 0. They can make a request to have their object at a certain location, but the kernel is entirely likely to reject their request because it is pinned to hardware. > I realise that the first submitted patch didn't cover the GTT case, > since the first indication I got was that not only was there a > special case for GTT to need page 0 for other things, but also that > this was "good enough" for opencl, but it seems that a full solution > would be needed. Exactly. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
