On Fri, Nov 20, 2015 at 03:07:58PM +0530, Ankitprasad Sharma wrote: > On Wed, 2015-11-18 at 10:59 +0100, Daniel Vetter wrote: > > On Thu, Nov 05, 2015 at 05:15:59PM +0530, ankitprasad.r.sharma@xxxxxxxxx wrote: > > > From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> > > > > > > In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, > > > we try a nonblocking pin for the whole object (since that is fastest if > > > reused), then failing that we try to grab one page in the mappable > > > aperture. It also allows us to handle objects larger than the mappable > > > aperture (e.g. if we need to pwrite with vGPU restricting the aperture > > > to a measely 8MiB or something like that). > > > > We already have a fallback to the shmem pwrite. Why do we need this? > This is mainly for the non-shmem backed objects, as we do not have > fallback path for that. Agree for the shmem backed objects, as we > already have a fallback. > > Would like to request Chris, if he can clarify further. Exactly that, with stolen we cannot use the shmem path so there exists no fallback. In order to pwrite to stolen, the GTT path must be fully capable. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
