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

[Eric Anholt]

On Sun, 19 Jun 2011 17:28:11 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sat, 18 Jun 2011 13:20:05 -0700, Eric Anholt <eric at anholt.net> wrote:
> > On Sat, 18 Jun 2011 12:43:58 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > On Fri, 17 Jun 2011 12:06:54 -0700, Eric Anholt <eric at anholt.net> wrote:
> > > > On Wed, 15 Jun 2011 17:03:58 +0100, Chris Wilson <chris at 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.)

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?

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

I was talking about it being in libdrm_intel, sorry if that was
unclear.
-------------- 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/20110619/6af3e9e8/attachment.sig>