Re: [PATCH] [RFC] intel: Non-LLC based non-blocking maps.

[Chris Wilson <chris@chris-wilson.co.uk>]

On Mon, 18 Jun 2012 20:38:15 -0700, Ben Widawsky <ben@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