From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] [RFC] intel: Non-LLC based non-blocking maps. Date: Tue, 19 Jun 2012 09:22:03 +0100 Message-ID: <1340094148_12273@CP5-2952> References: <1340077095-14843-1-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id DBE009E7DD for ; Tue, 19 Jun 2012 01:22:31 -0700 (PDT) In-Reply-To: <1340077095-14843-1-git-send-email-ben@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: DRI Devel Cc: Daniel Vetter , Ben Widawsky , Intel GFX List-Id: intel-gfx@lists.freedesktop.org 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 -- Chris Wilson, Intel Open Source Technology Centre