Re: [Intel-gfx] updated -next

2012-02-20 Thread Sun, Yi
A new round of Kernel testing is finished. We covered the platforms IvyBridge, SandyBridge, IronLake, G33 and PineView. We use the latest version on drm-intel-testing branch: Kernel: (drm-intel-testing)de67cba65944f26c0f147035bd62e30c5f456b96 Some additional commit info: Author: Danny Kukawka Dat

Re: [Intel-gfx] [PATCH] drm/i915: Suppress warning for MTRR failure if PAT is enabled

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 19:20:03 +, Chris Wilson wrote: > Emitting a spurious warning about poor graphics performance when MTRR > are irrelevant leads to confused users and useless bug reports. Darn, a bigger nail in the coffin of this patch is the lack of EXPORT_SYMBOL for pat_enabled. -Chris

[Intel-gfx] [PATCH] tests/gem_ringfill: Exercise all rings

2012-02-20 Thread Chris Wilson
On SandyBridge, the BLT commands were split from the RENDER commands as well as the BSD split inherited from Ironlake. So we need to make sure we do exercise each ring, and in order to do so we also need to make sure each batch takes longer to execute than it takes for us to submit it. v2: Exercis

Re: [Intel-gfx] [PATCH 4/5] intel_reg_dumper: Add dumping of GPU turbo regs.

2012-02-20 Thread Paul Menzel
Dear Eric, Am Montag, den 20.02.2012, 10:04 -0800 schrieb Eric Anholt: > I was interested in finding why my IVB system is not getting GPU turbo > after suspend/resume. The piece that looks weird to me is that > INTERRUPT_THRESHOLD is sitting at 0, whereas pre-suspend it's > 0x1200. are all

Re: [Intel-gfx] [PATCH] tests/gem_ringfill: Exercise all rings

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 22:22:00 +, Chris Wilson wrote: > On SandyBridge, the BLT commands were split from the RENDER commands as > well as the BSD split inherited from Ironlake. So we need to make sure > we do exercise each ring, and in order to do so we also need to make > sure each batch takes

[Intel-gfx] [PATCH] tests/gem_ringfill: Exercise all rings

2012-02-20 Thread Chris Wilson
On SandyBridge, the BLT commands were split from the RENDER commands as well as the BSD split inherited from Ironlake. So we need to make sure we do exercise each ring, and in order to do so we also need to make sure each batch takes longer to execute than it takes for us to submit it. Signed-off-

Re: [Intel-gfx] [PATCH 5/5] gem_ringfill: Make this actually test that all the batches executed.

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 10:04:02 -0800, Eric Anholt wrote: > I was looking into some strange behavior in Mesa that looks like > batches maybe being skipped, but this test didn't catch it. After a little bit of experimenting with dummy loads, the bug only seems to manifest itself on the render ring. -

Re: [Intel-gfx] [PATCH 5/5] gem_ringfill: Make this actually test that all the batches executed.

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 10:04:02 -0800, Eric Anholt wrote: > I was looking into some strange behavior in Mesa that looks like > batches maybe being skipped, but this test didn't catch it. Even if it doesn't yet hit the error, it looks a good step towards such a test case. Reviewed-by: Chris Wilson -

Re: [Intel-gfx] batchbuffers failing to execute

2012-02-20 Thread Daniel Vetter
On Mon, Feb 20, 2012 at 08:30:39PM +, Chris Wilson wrote: > On Mon, 20 Feb 2012 12:10:49 -0800, Eric Anholt wrote: > > This is gen7, danvet's kernel de67cba65944f26c0f147035bd62e30c5f456b96 > > rebased on top of cherry-picks of the 4 ivb workaround patches. A > > revert of a71d8d94525e8fd855c

Re: [Intel-gfx] [PATCH] drm/i915: Suppress warning for MTRR failure if PAT is enabled

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 12:21:43 -0800, Eric Anholt wrote: > Now that PAT has been reliable without MTRRs in place for a while, I > agree with the patch (but not with removing the braces around the > multi-line printf). I thought the braces around the single line was a checkpatch violation. Having ru

Re: [Intel-gfx] [PATCH] drm/i915: Suppress warning for MTRR failure if PAT is enabled

2012-02-20 Thread Eric Anholt
On Mon, 20 Feb 2012 19:20:03 +, Chris Wilson wrote: > Emitting a spurious warning about poor graphics performance when MTRR > are irrelevant leads to confused users and useless bug reports. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=41648 > Signed-off-by: Chris Wilson Now

[Intel-gfx] [PATCH 1/2] Try to ensure that batches emitted actually complete.

2012-02-20 Thread Eric Anholt
--- src/mesa/drivers/dri/i965/brw_state_upload.c |2 + src/mesa/drivers/dri/intel/intel_batchbuffer.c | 73 src/mesa/drivers/dri/intel/intel_batchbuffer.h |2 + 3 files changed, 77 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_state_

Re: [Intel-gfx] batchbuffers failing to execute

2012-02-20 Thread Chris Wilson
On Mon, 20 Feb 2012 12:10:49 -0800, Eric Anholt wrote: > This is gen7, danvet's kernel de67cba65944f26c0f147035bd62e30c5f456b96 > rebased on top of cherry-picks of the 4 ivb workaround patches. A > revert of a71d8d94525e8fd855c0466fb586ae1cb008f3a2 doesn't help. You need the bug fix that was mea

[Intel-gfx] [PATCH 2/2] intel: Disable swap throttling entirely.

2012-02-20 Thread Eric Anholt
This reveals some major breakage in the kernel. --- src/mesa/drivers/dri/intel/intel_context.c | 22 -- 1 files changed, 0 insertions(+), 22 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 377bcbc..5733

[Intel-gfx] batchbuffers failing to execute

2012-02-20 Thread Eric Anholt
I think I've got a concrete test here for something I've been trying to track down for a while now: it appears that when the GPU is too busy, batches get dropped and sometimes the GPU hangs. This really became clear when I was testing a patch for citybench to "improve" the swap throttling -- a bro

[Intel-gfx] [PATCH] drm/i915: Suppress warning for MTRR failure if PAT is enabled

2012-02-20 Thread Chris Wilson
Emitting a spurious warning about poor graphics performance when MTRR are irrelevant leads to confused users and useless bug reports. References: https://bugs.freedesktop.org/show_bug.cgi?id=41648 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c |4 ++-- 1 files changed, 2 ins

[Intel-gfx] [PATCH 5/5] gem_ringfill: Make this actually test that all the batches executed.

2012-02-20 Thread Eric Anholt
I was looking into some strange behavior in Mesa that looks like batches maybe being skipped, but this test didn't catch it. --- tests/gem_ringfill.c | 65 ++--- 1 files changed, 61 insertions(+), 4 deletions(-) diff --git a/tests/gem_ringfill.c b/tes

[Intel-gfx] [PATCH 1/5] instdone: Fix fallthroughs to invalid instdone bits on newer hardware.

2012-02-20 Thread Eric Anholt
--- lib/instdone.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/lib/instdone.c b/lib/instdone.c index 3e4d895..e12982c 100644 --- a/lib/instdone.c +++ b/lib/instdone.c @@ -25,6 +25,7 @@ * */ +#include #include "instdone.h" #include "intel_chipset.h" @@ -23

[Intel-gfx] [PATCH 4/5] intel_reg_dumper: Add dumping of GPU turbo regs.

2012-02-20 Thread Eric Anholt
I was interested in finding why my IVB system is not getting GPU turbo after suspend/resume. The piece that looks weird to me is that INTERRUPT_THRESHOLD is sitting at 0, whereas pre-suspend it's 0x1200. --- lib/intel_reg.h | 31 +++ tools/intel_reg_dump

[Intel-gfx] [PATCH 2/5] instdone: Add support for one of the IVB instdone regs.

2012-02-20 Thread Eric Anholt
--- lib/instdone.c | 24 +++- 1 files changed, 23 insertions(+), 1 deletions(-) diff --git a/lib/instdone.c b/lib/instdone.c index e12982c..fe001ca 100644 --- a/lib/instdone.c +++ b/lib/instdone.c @@ -135,10 +135,32 @@ init_g4x_instdone1(void) gen4_instdone1_bit(G4X_

[Intel-gfx] [PATCH 3/5] reg_dumper: Refactor duplicated reg-dumping code.

2012-02-20 Thread Eric Anholt
--- tools/intel_reg_dumper.c | 73 +++--- 1 files changed, 17 insertions(+), 56 deletions(-) diff --git a/tools/intel_reg_dumper.c b/tools/intel_reg_dumper.c index ee0ca75..c5249cb 100644 --- a/tools/intel_reg_dumper.c +++ b/tools/intel_reg_dumper.c @@ -1

[Intel-gfx] [PATCH 2/4] intel: Add decode for gen7 3DSTATE_WM.

2012-02-20 Thread Eric Anholt
This requires pulling the gen6 3DSTATE_WM out to a function so it doesn't override gen7's handler. --- intel/intel_decode.c | 178 - intel/tests/gen7-3d.batch-ref.txt | 70 +++ 2 files changed, 150 insertions(+), 98 deletions(-) diff

[Intel-gfx] [PATCH 1/4] intel: Fix a typo in decode error message.

2012-02-20 Thread Eric Anholt
--- intel/intel_decode.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index f33fb11..00908d0 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -2984,7 +2984,7 @@ decode_3d_965(struct drm_intel_decode *ctx)

[Intel-gfx] [PATCH 3/4] intel: Add decode for gen7 HIER_DEPTH_BUFFER.

2012-02-20 Thread Eric Anholt
Note that the regression test complains here: The batch that was captured included a bug in its packet output, which was later fixed in Mesa. --- intel/intel_decode.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c