public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 08/17] drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt
Date: Thu, 23 Apr 2015 20:56:40 +0200	[thread overview]
Message-ID: <20150423185640.GA30184@phenom.ffwll.local> (raw)
In-Reply-To: <20150423154352.GL21511@nuc-i3427.alporthouse.com>

On Thu, Apr 23, 2015 at 04:43:52PM +0100, Chris Wilson wrote:
> On Fri, Apr 17, 2015 at 04:49:18PM +0300, Mika Kuoppala wrote:
> > Daniel Vetter <daniel@ffwll.ch> writes:
> > 
> > > On Tue, Apr 14, 2015 at 06:53:41PM +0100, Chris Wilson wrote:
> > >> On Tue, Apr 14, 2015 at 07:11:25PM +0200, Daniel Vetter wrote:
> > >> > On Tue, Apr 14, 2015 at 05:06:36PM +0100, Chris Wilson wrote:
> > >> > > On Tue, Apr 14, 2015 at 05:35:18PM +0200, Daniel Vetter wrote:
> > >> > > > We load the ppgtt ptes once per gpu reset/driver load/resume and
> > >> > > > that's all that's needed. Note that this only blows up when we're
> > >> > > > using the allocate_va_range funcs and not the special-purpose ones
> > >> > > > used. With this change we can get rid of that duplication.
> > >> > > 
> > >> > > Honestly, I would prefer the test to be rewritten so that the
> > >> > > information on which vm was being used was passed along and not that
> > >> > > magic sprinkled in the middle of nowhere. e.g. execbuffer knows exactly
> > >> > > what vm it bound the objects into, and yet towards the end we decide to
> > >> > > guess again. Also, I would rather the execbuffer test be moved to
> > >> > > i915_gem_context since it is scattering internal knowledge about.
> > >> > 
> > >> > Yeah I agree that there's more room for cleanup. I've done this minimal
> > >> > patch purely to shut up the bogus WARN_ONs when I tried to unify the
> > >> > gen6/7 pt alloc code in the next patch. Since it's bogus.
> > >> 
> > >> How about:
> > >
> > > Yeah, but imo there's also more. I tried to understand the gen8 legacy ctx
> > > switch logic and failed, and I wasn't fully convinced that the gen7 one
> > > won't WARN if we actually enable full ppgtt. Given all that I decided to
> > > go with the most minimal patch and just removed the offending bogus WARN.
> > > But Mika/Michel promised to hang around for eventual cleanups?
> > 
> > Yes. There is more to come after this series.
> > I can include Chris's suggestion.
> 
> Looking at this WARN that fires continually on gen6/gen7, (it's nice to
> have such a blatant WARN to explain the perf decrease), don't we need
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index a1a9f5dad541..006d4a2610f7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1562,6 +1562,8 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
>                         ret = ppgtt->switch_mm(ppgtt, ring);
>                         if (ret != 0)
>                                 return ret;
> +
> +                       ppgtt->pd_dirty_rings &= ~(1 << i);
>                 }
>         }

Yeah, but I didn't really see the point in the debug infrastructure for
aliasing ppgtt. The pde loading is done somewhere completely else than for
full ppgtt. And if we forget to load the pdes the effects are obvious,
whereas failing to reload when changes happen with full ppgtt is much
harder to spot quickly. So I opted to undo those checks again, they have
been defunct before my changes anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-04-23 18:54 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14 15:35 [PATCH 00/17] i915_gem_gtt.c polish Daniel Vetter
2015-04-14 15:35 ` [PATCH 01/17] drm/i915: Move gen8 clear_range vfunc setup into common code Daniel Vetter
2015-04-17 14:11   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 02/17] drm/i915: Move vma vfuns to adddress_space Daniel Vetter
2015-04-14 16:09   ` Chris Wilson
2015-04-14 16:12     ` Chris Wilson
2015-04-14 17:08       ` Daniel Vetter
2015-04-14 17:23         ` Chris Wilson
2015-04-16  6:18     ` Mika Kuoppala
2015-04-16  7:39       ` Chris Wilson
2015-04-17 14:15   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 03/17] drm/i915: Clean up aliasing ppgtt correctly on error paths Daniel Vetter
2015-04-17 14:34   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 04/17] drm/i915: Unify aliasing ppgtt handling Daniel Vetter
2015-04-17 13:36   ` Mika Kuoppala
2015-04-17 16:21   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 05/17] drm/i915: Move PTE_READ_ONLY to ->pte_encode vfunc Daniel Vetter
2015-04-17 16:22   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 06/17] drm/i915: Dont clear PIN_GLOBAL in the execbuf pinning fallback Daniel Vetter
2015-04-14 15:53   ` Chris Wilson
2015-04-14 16:33     ` Chris Wilson
2015-04-14 17:01   ` [PATCH] " Daniel Vetter
2015-04-15 21:50     ` shuang.he
2015-04-14 15:35 ` [PATCH 07/17] drm/i915: Drop redundant GGTT rebinding Daniel Vetter
2015-04-14 16:03   ` Chris Wilson
2015-04-14 15:35 ` [PATCH 08/17] drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt Daniel Vetter
2015-04-14 16:06   ` Chris Wilson
2015-04-14 17:11     ` Daniel Vetter
2015-04-14 17:53       ` Chris Wilson
2015-04-15 10:44         ` Daniel Vetter
2015-04-17 13:49           ` Mika Kuoppala
2015-04-20 16:02             ` Daniel Vetter
2015-04-20 16:08             ` Daniel Vetter
2015-04-21  8:18               ` Mika Kuoppala
2015-04-23 15:43             ` Chris Wilson
2015-04-23 18:56               ` Daniel Vetter [this message]
2015-04-23 19:52                 ` Chris Wilson
2015-04-23 21:52                 ` Chris Wilson
2015-07-31 16:26                 ` Chris Wilson
2015-07-31 17:38                   ` Chris Wilson
2015-04-14 15:35 ` [PATCH 09/17] drm/i915: Don't use atomics for pg_dirty_rings Daniel Vetter
2015-04-17 16:39   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 10/17] drm/i915: Remove misleading comment around bind_to_vm Daniel Vetter
2015-04-17 18:09   ` Mika Kuoppala
2015-04-14 15:35 ` [PATCH 11/17] drm/i915: Fix up the vma aliasing ppgtt binding Daniel Vetter
2015-04-15 10:47   ` Chris Wilson
2015-04-16  8:01     ` Daniel Vetter
2015-04-16  8:07       ` Chris Wilson
2015-04-16  8:57         ` Daniel Vetter
2015-04-20 16:04   ` [PATCH] " Daniel Vetter
2015-04-21 13:29     ` Mika Kuoppala
2015-04-24 11:14     ` Chris Wilson
2015-04-24 11:55       ` Chris Wilson
2015-05-04  8:49         ` Daniel Vetter
2015-05-04  9:06           ` Chris Wilson
2015-05-04  9:20             ` Daniel Vetter
2015-04-14 15:35 ` [PATCH 12/17] drm/i915: Arm cmd parser with aliasng ppgtt only Daniel Vetter
2015-04-14 18:10   ` Chris Wilson
2015-04-15  9:43     ` Daniel Vetter
2015-04-15 10:07       ` Chris Wilson
2015-04-15 10:28         ` Daniel Vetter
2015-04-30 10:37           ` Jani Nikula
2015-04-24 12:57   ` Mika Kuoppala
2015-05-04  8:54     ` [PATCH] drm/i915: Simplify cmd-parser DISPATCH_SECURE check Daniel Vetter
2015-05-04  9:23       ` Daniel Vetter
2015-05-04 12:52       ` shuang.he
2015-04-14 15:35 ` [PATCH 13/17] drm/i915: move i915_gem_restore_gtt_mappings around Daniel Vetter
2015-04-14 15:35 ` [PATCH 14/17] drm/i915: Move ppgtt_bind/unbind around Daniel Vetter
2015-04-14 15:35 ` [PATCH 15/17] drm/i915: Unduplicate i915_ggtt_unbind/bind_vma Daniel Vetter
2015-04-14 15:35 ` [PATCH 16/17] drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c Daniel Vetter
2015-04-14 15:35 ` [PATCH 17/17] drm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma Daniel Vetter
2015-04-21 13:36   ` Mika Kuoppala
2015-04-23 19:08     ` Daniel Vetter
2015-04-15 10:49 ` [PATCH 00/17] i915_gem_gtt.c polish Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150423185640.GA30184@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox