On Wed, 22 Jun 2011 09:20:35 -0700, Keith Packard <kei...@keithp.com> wrote: > On Wed, 22 Jun 2011 08:29:24 +0200, Daniel Vetter <dan...@ffwll.ch> wrote: > > > The important thing is that you may never use the cpu mappings with > > these functions (for objects of similar size). Because libdrm reuses > > bos without checking their domain, you'll get tons of unnecessary > > clflush even on objects that do not get accessed through the cpu > > domain. > > Yeah, the problem is that a BO which is not pinned down may get paged > out, in which case it lands in the CPU domain. I'm not sure we've ever > added an optimization to avoid flushing objects which are known not to > have been written to disk?
I've toyed with such. Can be very effective for large working sets like firefox thrashing the aperture. A very simple example is firefox-planet-gnome which demonstrates the effect just by scrolling within a single page on gen3. [The trace currently spends 35% of its time in clflush which can be entirely eliminated by such tracking.] There's also the secondary benefit that shmemfs is quite slow for our purposes. -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
