[Intel-gfx] [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain"

[Eric Anholt]

On Wed, 15 Jun 2011 10:39:06 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Tue, 14 Jun 2011 16:43:09 -0700, Eric Anholt <eric at 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.

We rely on userspace to get it right all the time, which was a design
decision made early on for performance reasons.  For example, userspace
can submit the wrong domains with an exec call, and non-GTT mappings
also behave like I'm changing GTT back to.  Unless you quietly changed
that, too?

> > 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?

Page table changes are expensive, yes.  That's why we cache BOs in
userspace and hang onto the mappings of them.  We only moved to GTT
mappings in Mesa in places where it was faster than the alternatives (or
for tiled buffers, where due to the a17 swizzling there is no other
option).

> 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

I was testing with semaphores enabled on the LLC series.  I'm curious
how this revert could possibly regress cairo-xlib, though -- that seems
very strange.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20110615/d7b65b52/attachment.sig>