From: Ben Widawsky <ben@bwidawsk.net>
To: Keith Packard <keithp@keithp.com>,
"Airlie, Dave" <airlied@linux.ie>,
Intel drivers <Intel-gfx@lists.freedesktop.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PULL] drm-intel-next
Date: Thu, 05 Jan 2012 09:58:36 -0800 [thread overview]
Message-ID: <4F05E4CC.1040705@bwidawsk.net> (raw)
In-Reply-To: <20120105152408.GD3831@phenom.ffwll.local>
On 01/05/2012 07:24 AM, Daniel Vetter wrote:
> On Wed, Jan 04, 2012 at 07:35:41PM -0800, Keith Packard wrote:
>>
>> Here are the rest of the 3.3 pending changes.
>>
>> This has a bunch of small bug fixes and overlay plane support for i915.
>>
>> The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60:
>>
>> Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next (2012-01-03 09:45:12 +0000)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux drm-intel-next
>
> I'm not happy with Eric's missed IRQ workaround because
> - it's incomplete, the BSD ring is similarly affected by these issues like
> the blitter ring, but not handled by his patches.
> - it does a busy-loop wait until the gpu signals completion - in normal
> useage this can easily be a few msecs, especially since now semaphores
> are enabled by defailt on Ivybridge. With offscreen benchmarking it can
> easily reach seconds. This is imo unacceptable.
>
> Furthermore
> - Chris Wilson proposed an alternative approach quite a bit before these
> patches have been created that combines the irq signalling path with a
> short timer as a backup. This works really well because we only rarely
> miss irqs. See
> Message-Id:<1323978198-3501-1-git-send-email-chris@chris-wilson.co.uk>
> - Meanwhile I've discovered a magic set of tricks that seem to completely
> solve missed irq issues on both ivb and snb. This would render all this
> ducttape irrelevant.
>
> Imo the minimal right thing to do is to revert the patch "drm/i915: Make
> the fallback IRQ wait not sleep". This will regress piglit throughput (and
> anything else stupid enough to crazily ping-pong between the gpu and cpu)
> quite a bit, but honestly that's not something our userbase cares about.
>
> I'd also like to express my frustration with the general -next process for
> drm/i915:
> - This drm-intel-next tree is less than 24h ours old (if you look at when
> it showed up at an official place where both our QA and the community
> can pick it up and test it). I fear we'll ship yet another disaster like
> the stack eating bug the vt-d/ilk w/a patch caused with an unbounded
> recursion. Our QA actually caught it in testing, but there was simply
> not enough time to fix things up before the buggy code landed in -linus.
> - Because the drm-intel-next merge cycle started so late there has simply
> not been enough time to include quite a few bugfixes for serious issues
> like 20s delays in intial modeset, userspace-triggerable kernel OOPSes
> and deadlocks and reproducible hard hw hangs. For most of these there
> are testcases in intel-gpu-tools, and these issues span the entire set
> of hw generations drm/i915 currently supports. But this late it's imo
> no longer advisible to merge them, so we'll ship 3.3 with a bunch of
> known (and sometimes longstanding) serious issues that have fixes.
>
> Yours, Daniel
I'd like to echo my concerns regarding late merging and therefore lack
of QA testing. I ended up looking like quite the fool last time around,
and that would have been prevented with QA testing of intel-gpu-tools.
next prev parent reply other threads:[~2012-01-05 17:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 3:35 [PULL] drm-intel-next Keith Packard
2012-01-05 15:24 ` Daniel Vetter
2012-01-05 17:58 ` Ben Widawsky [this message]
2012-01-05 18:02 ` [Intel-gfx] " Jesse Barnes
2012-09-13 14:18 [pull] drm-intel-next Daniel Vetter
2012-09-14 13:55 ` [Intel-gfx] " Bobby Powers
2012-09-14 15:43 ` Daniel Vetter
2012-09-14 19:52 ` Paulo Zanoni
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=4F05E4CC.1040705@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).