Message-ID: <4F05E4CC.1040705@bwidawsk.net>
Date:	Thu, 05 Jan 2012 09:58:36 -0800
From:	Ben Widawsky <ben@...dawsk.net>
To:	Keith Packard <keithp@...thp.com>,
	"Airlie, Dave" <airlied@...ux.ie>,
	Intel drivers <Intel-gfx@...ts.freedesktop.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PULL] drm-intel-next

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@...is-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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists