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

Daniel Vetter daniel at ffwll.ch
Tue Nov 24 04:22:16 PST 2015


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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list