From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Clifton Subject: Re: Corruption in glxgears with Compiz Date: Sat, 23 Oct 2010 04:35:46 +0100 Message-ID: <1287804946.9701.3.camel@pcjc2lap> References: <1287751996.19922.4.camel@pcjc2lap> <849307$a3hfvt@azsmga001.ch.intel.com> <1287774644.17191.9.camel@pcjc2lap> <5b55a1$ien4q1@fmsmga002.fm.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by gabe.freedesktop.org (Postfix) with ESMTP id CDD7E9E789 for ; Fri, 22 Oct 2010 20:35:48 -0700 (PDT) In-Reply-To: <5b55a1$ien4q1@fmsmga002.fm.intel.com> 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: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, 2010-10-22 at 20:29 +0100, Chris Wilson wrote: > On Fri, 22 Oct 2010 20:10:44 +0100, Peter Clifton wrote: > > As an additional data-point, with the bug manifesting, if you go to > > "expose" mode, (Win+E for default config), you find the corruption is > > absent. It only appears to be present when the glxgears window is not > > scaled by the window manager. > > My guess is that it is a double application of the drawable offset when > doing a CopyRegion swapbuffers. Does the corruption move in relation to > the window as it moves? > > This suggests that [my] recent changes to the ddx are to blame, and > certainly a bisection on -intel might help - though it's probably just as > easy to test before the shadow+dri changes to confirm. > -Chris Lost of bisecting and backporting later.. and I've identified the bad commit: 9220434a8768902cd9cf248709972678b74aa8c1 drm/i915: Only emit a flush request on the active ring. I'm not sure what the correct fix is, but a workaround is this: Actually, I've not tested that yet.. oops. It certainly works with the if(1) and if (obj->write_domain) bypassing the test for ... & I915_GEM_GPU_DOMAIN. That wasn't enough alone though, it didn't work until I changed: - if (flush_rings & RING_RENDER) + if (1) Presumably some object is not getting the RENDER_RING added to the flush_rings field correctly. git diff HEAD^ diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index cf27655..a9d528e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1901,7 +1901,9 @@ i915_gem_flush(struct drm_device *dev, drm_agp_chipset_flush(dev); if ((flush_domains | invalidate_domains) & I915_GEM_GPU_DOMAINS) { - if (flush_rings & RING_RENDER) +// if (1) { +// if (flush_rings & RING_RENDER) + if (1) i915_gem_flush_ring(dev, &dev_priv->render_ring, invalidate_domains, flush_domains); @@ -4197,6 +4199,7 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data, * flush earlier is beneficial. */ if (obj->write_domain & I915_GEM_GPU_DOMAINS) { +// if (obj->write_domain) { i915_gem_flush_ring(dev, obj_priv->ring, 0, obj->write_domain); -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)