[Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast
ankitprasad.r.sharma at intel.com
Mon Dec 14 00:19:36 PST 2015
On Tue, 2015-11-24 at 13:22 +0100, Daniel Vetter wrote:
> 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 at intel.com wrote:
> > > > > From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> > > > >
> > > > > 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.
I have moved this patch to the stolen memory series with the latest
version. Can we please move ahead for the review and merge of the first
More information about the Intel-gfx