On Mon, 18 Jun 2012 20:38:15 -0700, Ben Widawsky <ben at bwidawsk.net> wrote: > The history on this patch goes back quite a way. This time around, the > patch builds on top of the map_unsynchronized that Eric pushed. Eric's > patch attempted only to solve the problem for LLC machines. Unlike > my earlier versions of this patch (with the help from Daniel Vetter), we > do not attempt to cpu map objects in a unsynchronized manner. > > The concept is fairly simple - once a buffer is moved into the GTT > domain, we can assume it remains there unless we tell it otherwise (via > cpu map). It therefore stands to reason that as long as we can keep the > object in the GTT domain, and don't ever count on reading back contents, > things might just work. I believe as long as we are doing GTT mappings > only, we get to avoid worry about clflushing the dirtied cachelines, but > that could use some fact checking. > > The patch makes some assumptions about how the kernel does buffer > tracking, this could be conceived as an ABI dependency, but actually the > behavior is pretty confined. It exploits the fact the BOs are only moved > into the CPU domain under certain circumstances, and daintily dances > around those conditions. The main thing here is we assume MADV_WILLNEED > prevents the object from getting evicted. > > I am not aware of a good way to test it's effectiveness > performance-wise; but it introduces no regressions with piglit on my > ILK, or SNB. This is broken wrt to cache invalidation if I want to rewrite part of the buffer that already has been read by the GPU. -Chris -- Chris Wilson, Intel Open Source Technology Centre
