[Intel-gfx] [PATCH] drm/i915: Skip waking the device to service pwrite

[Daniel Vetter]

On Mon, Sep 04, 2017 at 11:18:07AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-09-04 09:12:12)
> > On Wed, Aug 30, 2017 at 06:48:19PM +0100, Chris Wilson wrote:
> > > If the device is in runtime suspend, resuming takes time and reduces our
> > > powersaving. If this was for a small write into an object, that resume
> > > will take longer than any savings in using the indirect GGTT access to
> > > avoid the cpu cache.
> > > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c | 21 ++++++++++++++++++---
> > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > > index 93dfa793975a..8940a6873ca5 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -1229,7 +1229,21 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
> > >       if (ret)
> > >               return ret;
> > >  
> > > -     intel_runtime_pm_get(i915);
> > > +     if (i915_gem_object_has_struct_page(obj)) {
> > 
> > I don't really see why we need to check for has_struct_page here (we do
> > already outside the lock grabbing), and why if that's not the case we hit
> > the slow-path?
> 
> We can't use the alternate paths if we don't have struct_page, hence we
> have to force use of GTT if !i915_gem_object_has_struct_page. The
> previous test is to also make sure we come down this path and not fail.

Ow, I've entirely misread all the code, I thought this checks for
obj->pages. With clue gained on my side:

Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch