From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] Revert "drm/i915: Kill GTT mappings when moving from GTT domain" Date: Sun, 19 Jun 2011 22:49:36 +0100 Message-ID: <013811$h8tfb@fmsmga002.fm.intel.com> References: <1308094989-3153-1-git-send-email-eric@anholt.net> <87tybrcet0.fsf@eliezer.anholt.net> <87mxhg5lbl.fsf@eliezer.anholt.net> <87liwyao3u.fsf@eliezer.anholt.net> <013811$h7gjb@fmsmga002.fm.intel.com> <87y60xpxgc.fsf@eliezer.anholt.net> <87zkld8qnl.fsf@eliezer.anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id D2D3A9E787 for ; Sun, 19 Jun 2011 14:49:39 -0700 (PDT) In-Reply-To: <87zkld8qnl.fsf@eliezer.anholt.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: Eric Anholt , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Sun, 19 Jun 2011 14:20:14 -0700, Eric Anholt wrote: > On Sun, 19 Jun 2011 18:14:11 +0100, Chris Wilson wrote: > > On Sun, 19 Jun 2011 10:01:23 -0700, Eric Anholt wrote: > > > On Sun, 19 Jun 2011 17:28:11 +0100, Chris Wilson wrote: > > > > For lack of a better mechanism. Even using anholt/gtt-revert, I question > > > > the value of caching the GTT mapping in drm_intel_bo. For the cairo-gl and > > > > pts benchmarks I've run, the efficacy of the cached vma is very small and > > > > there is a very slight improvement by unmapping the vma after use. (The > > > > difference is so small, that it will take a lot more runs to determine if > > > > it is statistically significant.) > > > > > > I'm confused. You've measured a 5% impact from removing this part of > > > the caching, and I've measured 12-19%, so what are you planning that > > > doesn't involve caching the mapping that's faster than caching the > > > mapping? > > > > As I pointed out, cairo-gl is using fallback code and not spans. Once that > > is corrected, cairo-gl no longer continually recreating textures and so > > unaffected by the patch. Removing the cached vma is then arguably > > beneficial, though the difference looks to be in the noise. > > So you don't actually want us to fix the performance regression in > texture uploads, and instead want to just tell applications not to > upload textures? Nowhere, did I say that. I just said you were optimising for broken code and papering over bugs and lack of functionality elsewhere. The patch closes a race condition. The essence of your complaint is that the kernel is not as fast as we need it to be, and that the initial upload to any object is slower than expected. I presume you also have a plan for fixing the underwhelming performance of a glibc memcpy through an established GTT mapping? > What about applications where we're not the authors, and where they > don't have a choice but to upload textures (media players)? No, I'm not necessarily saying application code is broken, just the library. -Chris -- Chris Wilson, Intel Open Source Technology Centre