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

[Chris Wilson <chris@chris-wilson.co.uk>]

On Sat, 18 Jun 2011 13:20:05 -0700, Eric Anholt <eric@anholt.net> wrote:
> On Sat, 18 Jun 2011 12:43:58 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Fri, 17 Jun 2011 12:06:54 -0700, Eric Anholt <eric@anholt.net> wrote:
> > > On Wed, 15 Jun 2011 17:03:58 +0100, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > Moving back to LLC+semaphores (2.6.39-rc2+), firefox-talos-gfx:
> > > > xlib: 4.473
> > > > gl:  20.753
> > > > 
> > > > applying the patch:
> > > > xlib: 4.472
> > > > gl:  20.824
> > > > 
> > > > I'm just not reproducing the same issue you are seeing. Are you using a
> > > > standard distro Kconfig, or if not, can you send me yours?
> > > > -Chris
> > > 
> > > http://people.freedesktop.org/~anholt/dotconfig
> > > 
> > > Pushed my kernel tree to "gtt-revert" branch.
> > 
> > Thanks, I'm testing with those on my SNB desktop, still only see around
> > a 5% hit for firefox-talos-gfx.
> 
> GTT mappings are important.  They're how textures are uploaded in GL in
> general.

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.)

> One of the longstanding things I've wanted to do for GL
> applications that repeatedly allocate new texture images is to userland
> BO cache those objects, which we don't do because of tiling.

I'm failing to see the difference between this cache and a slightly
smarter (i.e. one that preferentially returns an object with appropriate
tiling and busy status) libdrm_intel cache.

> With the
> patch I'm reverting in place, there's basically no reason to do so
> because remapping the BO is much of the cost of recreating the BO from
> scratch.  Remapping is the reason we do userland caching instead of
> kernel-side caching.

Conversely, it is the lack of such a kernel bo and page cache that is
determinental to the ddx (at least on pre-SNB). And for any system running
more than one renderer. [Except for the thorny issue of whether having to
clear the pages returned from such a cache will nullify its benefits. I
have yet to measure the impact of doing so.]
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre