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: Wed, 15 Jun 2011 10:39:06 +0100 [thread overview]
Message-ID: <aefc95$e8b9g@orsmga001.jf.intel.com> (raw)
In-Reply-To: <1308094989-3153-1-git-send-email-eric@anholt.net>
On Tue, 14 Jun 2011 16:43:09 -0700, Eric Anholt <eric@anholt.net> wrote:
> This reverts commit 4a684a4117abd756291969336af454e8a958802f.
> Userland has always been required to set the object's domain to GTT
> before using it through a GTT mapping, it's not something that the
> kernel is supposed to enforce. (The pagefault support is so that we
> can handle multiple mappings without userland having to pin across
> them, not so that userland can use GTT after GPU domains without
> telling the kernel).
The only place that can do accurate per-page tracking of domains is the
kernel. (And avoid clflushes for GTT eviction. Ok, so we're not quite
there yet.) Relying on userspace to get it right, and for co-operating
processes to coordinate their access to buffers is a misfeature.
> Fixes 19.2% +/- 0.8% (n=6) performance regression in cairo-gl
> firefox-talos-gfx on my T420 latop.
Since GTT mappings are fundamentally slow, don't you think this suggests
that mesa is doing something wrong? Or a bug in cairo-gl to make mesa act
this way?
For the record, on my SugarBay, this patch on top of drm-intel-fixes and
mesa.git + your instruction streaming, regresses cairo-xlib 4.5s to 4.7s
(4%, with a claim of .1% stddev) and improves cairo-gl from 21.5s to 20.1s
(6.5%, with a claim of .5% stddev) for the firefox-talos-gfx. [This is a
system that can do under 2s for cairo-xlib using vmap and the perf
patches I posted before.]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2011-06-15 9:39 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 [this message]
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
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='aefc95$e8b9g@orsmga001.jf.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.