[Intel-gfx] [PATCH 3/3] drm/i915: Use insert_page for pwrite_fast

Chris Wilson chris at chris-wilson.co.uk
Fri Nov 20 02:06:16 PST 2015


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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list