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
Ben Widawsky (4): drm/i915: relative_constants_mode race fix drm/i915: Force sync command ordering (Gen6+) drm/i915: Update GEN6_RP_CONTROL definitions drm/i915: drpc debugfs update for gen6
Daniel Vetter (2): drm/i915: kicking rings stuck on semaphores considered harmful drm/i915: don't bail out of intel_wait_ring_buffer too early
Eric Anholt (5): drm/i915: Set two chicken bits implicated in missed IRQs on Ivybridge. drm/i915: Do the fallback non-IRQ wait in ring throttle, too. drm/i915: Work around gen7 BLT ring synchronization issues. drm/i915: Make the fallback IRQ wait not sleep. drm/i915: Add support for resetting the SO write pointers on gen7.
Jesse Barnes (5): drm/i915: add SNB and IVB video sprite support v6 drm/i915: track sprite coverage and disable primary plane if possible drm/i915: add color key support v4 drm/i915: don't disable a PCH DPLL that's in use drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded
Keith Packard (1): drm/i915: Clean up multi-threaded forcewake patch
drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_debugfs.c | 86 ++++- drivers/gpu/drm/i915/i915_dma.c | 5 + drivers/gpu/drm/i915/i915_drv.c | 7 - drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/i915_gem.c | 10 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 63 +++- drivers/gpu/drm/i915/i915_irq.c | 7 - drivers/gpu/drm/i915/i915_reg.h | 161 +++++++- drivers/gpu/drm/i915/intel_display.c | 206 ++++++++- drivers/gpu/drm/i915/intel_drv.h | 40 ++ drivers/gpu/drm/i915/intel_fb.c | 6 + drivers/gpu/drm/i915/intel_ringbuffer.c | 30 ++- drivers/gpu/drm/i915/intel_sprite.c | 668 ++++++++++++++++++++++++++++ include/drm/i915_drm.h | 40 ++ 15 files changed, 1290 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_sprite.c
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
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.
On Thu, 5 Jan 2012 16:24:08 +0100 Daniel Vetter daniel@ffwll.ch wrote:
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.
Yeah I have to second this and additionally complain about the patch lossiness & latency. Part of this is my fault for not reviewing things as much as I should, but those reviews often get lost too...
Eugeni's i2c patches are a good example. They've been out there since early Oct, have received review and testing, and should have been in -next for many months now (in previous releases!).
What can we do to improve the process to get trees updated more regularly and get fixes integrated faster?
Thanks,
dri-devel@lists.freedesktop.org
-
Ben Widawsky -
Daniel Vetter -
Jesse Barnes -
Keith Packard