From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [Intel-gfx] [PATCH] [RFC] intel: Non-LLC based non-blocking maps. Date: Tue, 19 Jun 2012 09:13:20 -0700 Message-ID: <20120619091320.4a99b8c6@bwidawsk.net> References: <1340077095-14843-1-git-send-email-ben@bwidawsk.net> <1340094148_12273@CP5-2952> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1340094148_12273@CP5-2952> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: Daniel Vetter , Intel GFX , DRI Devel List-Id: intel-gfx@lists.freedesktop.org On Tue, 19 Jun 2012 09:22:03 +0100 Chris Wilson wrote: > On Mon, 18 Jun 2012 20:38:15 -0700, Ben Widawsky 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 > Well if you're talking about what I think you're talking about (ie. not clflushing, but simply dealing with the GPUs internal caching). It's a problem that has existed with all of the non-LLC non-blocking map patches; and sort of the point of non-blocking maps. Play it fast and loose, submit pipe controls if you get nervous. Did I catch your meaning, or were you just talking about clflushing stuff (we also miss chipset flush on really old platforms; I was thinking of restricting this to ILK only)? -- Ben Widawsky, Intel Open Source Technology Center