On Sat, 18 Jun 2011 13:20:05 -0700, Eric Anholt <e...@anholt.net> wrote: > On Sat, 18 Jun 2011 12:43:58 +0100, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > On Fri, 17 Jun 2011 12:06:54 -0700, Eric Anholt <e...@anholt.net> wrote: > > > On Wed, 15 Jun 2011 17:03:58 +0100, Chris Wilson > > > <ch...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
