From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position
Date: Wed, 8 Feb 2012 19:24:05 +0100 [thread overview]
Message-ID: <20120208182405.GF5030@phenom.ffwll.local> (raw)
In-Reply-To: <d08817$33o163@azsmga001.ch.intel.com>
On Wed, Feb 08, 2012 at 06:17:00PM +0000, Chris Wilson wrote:
> 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.
Well, that explains a few things. In that case I'm fine with just merging
the first patch for -fixes, I think there're quite a few bugs this does
fix.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-02-08 18:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-08 13:34 [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position Chris Wilson
2012-02-08 13:34 ` [PATCH 2/2] drm/i915: Record the tail at each request and use it to estimate the head Chris Wilson
2012-02-08 14:51 ` Daniel Vetter
2012-02-08 18:06 ` [PATCH] " Chris Wilson
2012-02-08 18:28 ` Daniel Vetter
2012-02-08 18:56 ` Eugeni Dodonov
2012-02-08 19:21 ` Chris Wilson
2012-02-08 14:54 ` [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position Daniel Vetter
2012-02-08 17:36 ` Keith Packard
2012-02-08 18:02 ` Daniel Vetter
2012-02-08 18:17 ` Chris Wilson
2012-02-08 18:24 ` Daniel Vetter [this message]
2012-02-08 19:13 ` Keith Packard
2012-02-08 20:09 ` [PATCH 1/2] drm/i915: Record the in-flight requests at the time of a hang Chris Wilson
2012-02-08 20:09 ` [PATCH 2/2] drm/i915: Record the position of the request upon error Chris Wilson
2012-02-08 22:34 ` Daniel Vetter
2012-02-10 14:51 ` Eugeni Dodonov
2012-02-08 22:33 ` [PATCH 1/2] drm/i915: Record the in-flight requests at the time of a hang Daniel Vetter
2012-02-21 19:23 ` [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position Eric Anholt
2012-02-27 16:53 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120208182405.GF5030@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox