[Intel-gfx] [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain"
Eric Anholt
eric at anholt.net
Sat Jun 18 22:20:05 CEST 2011
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. 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. 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.
-------------- 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/20110618/2804340c/attachment.sig>
More information about the Intel-gfx
mailing list