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 at 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.
