On Fri, Nov 20, 2015 at 10:06:16AM +0000, Chris Wilson wrote: > 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. Ok, in that case this should probably be part of the stolen obj series, just for clarification. -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
