All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Eric Anholt <eric@anholt.net>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain"
Date: Sun, 19 Jun 2011 18:14:11 +0100	[thread overview]
Message-ID: <d08817$eg36j@azsmga001.ch.intel.com> (raw)
In-Reply-To: <87y60xpxgc.fsf@eliezer.anholt.net>

On Sun, 19 Jun 2011 10:01:23 -0700, Eric Anholt <eric@anholt.net> wrote:
> On Sun, 19 Jun 2011 17:28:11 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > For lack of a better mechanism. Even using anholt/gtt-revert, I question
> > the value of caching the GTT mapping in drm_intel_bo. For the cairo-gl and
> > pts benchmarks I've run, the efficacy of the cached vma is very small and
> > there is a very slight improvement by unmapping the vma after use. (The
> > difference is so small, that it will take a lot more runs to determine if
> > it is statistically significant.)
> 
> I'm confused.  You've measured a 5% impact from removing this part of
> the caching, and I've measured 12-19%, so what are you planning that
> doesn't involve caching the mapping that's faster than caching the
> mapping?

As I pointed out, cairo-gl is using fallback code and not spans. Once that
is corrected, cairo-gl no longer continually recreating textures and so
unaffected by the patch. Removing the cached vma is then arguably
beneficial, though the difference looks to be in the noise.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2011-06-19 17:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 23:43 [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain" Eric Anholt
2011-06-15  9:39 ` Chris Wilson
2011-06-15 15:08   ` Eric Anholt
2011-06-15 16:03     ` Chris Wilson
2011-06-17 19:06       ` Eric Anholt
2011-06-18 11:43         ` Chris Wilson
2011-06-18 20:20           ` Eric Anholt
2011-06-19 16:28             ` Chris Wilson
2011-06-19 17:01               ` Eric Anholt
2011-06-19 17:14                 ` Chris Wilson [this message]
2011-06-19 21:20                   ` Eric Anholt
2011-06-19 21:49                     ` Chris Wilson
2011-06-21 16:17                       ` Remove the overhead of vm_insert_pfn() Chris Wilson
2011-06-21 16:17                         ` [PATCH 1/3] resource: Use a common string for .name = "System RAM" Chris Wilson
2011-06-21 16:17                         ` [PATCH 2/3] x86, pat: Perform interval rbtree lookup of memtype first Chris Wilson
2011-06-21 16:17                         ` [PATCH 3/3] x86, pat: Convert memtype_lock spinlock to a rwlock Chris Wilson
2011-06-21 18:09                       ` [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain" Keith Packard

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='d08817$eg36j@azsmga001.ch.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=eric@anholt.net \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.