From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [PATCH 1/2] drm/i915: Remove use of the
	autoreported ringbuffer HEAD position
Date: Wed, 08 Feb 2012 18:17:00 +0000
Message-ID: <d08817$33o163@azsmga001.ch.intel.com>
References: <1328708054-26350-1-git-send-email-chris@chris-wilson.co.uk>
	<20120208145425.GD5030@phenom.ffwll.local>
	<867gzxfcrm.fsf@sumi.keithp.com>
	<CAKMK7uFNUGf0oEf6MbygM803H=UFD8-Ci-8RHaafdmzz0a3JeA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mga03.intel.com (mga03.intel.com [143.182.124.21])
	by gabe.freedesktop.org (Postfix) with ESMTP id 8E75F9E789
	for <intel-gfx@lists.freedesktop.org>;
	Wed,  8 Feb 2012 10:17:06 -0800 (PST)
In-Reply-To: <CAKMK7uFNUGf0oEf6MbygM803H=UFD8-Ci-8RHaafdmzz0a3JeA@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=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: Daniel Vetter <daniel@ffwll.ch>, Keith Packard <keithp@keithp.com>
Cc: intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, 8 Feb 2012 19:02:47 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> The issue is that the first one introduces a pretty decent perf
> regression, iirc Chris mentions something much large than 10x slowdown
> on certain cairo traces on sna. So we can only merge the first one
> together with the second one.

As it turns out, the cairo-traces were successfully exploiting the
ringbuffer overflow to avoid work. The reason why it eventually broke is
that when I experimented with using the BLT and semaphores, I introduced
a dependency on accurate seqno processing, which was obviously broken by
the overwriting of commands in the ringbuffer. And so is consistent with
the hangs reported by Eugeni and Ben, but we have yet to see many more
examples in the wild. Otoh, I don't think this explains the
all-generation use-after-free bug.

Net result, the 0.9s firefox-paintball result was a fantasy and the perf
gains provided by the second patch are only around 20% for the same
trace. Ergo -next material only if it passes scrutiny.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre