Re: [Intel-gfx] [PATCH] drm/i915: Fix KMS regression on Sandybridge/CPT

On 2010.10.29 09:52:31 +0100, Chris Wilson wrote: > On Fri, 29 Oct 2010 10:34:51 +0800, Zhenyu Wang > wrote: > > On 2010.10.28 10:50:04 +0100, Chris Wilson wrote: > > > I've shrunk the patch to just the FDI portion, pushed to staging for > > > review. > > > > Current drm-intel-staging still fai

Re: [Intel-gfx] intel_prepare_render(intel); unhelpful?

On Mon, 2010-11-01 at 14:41 -0700, Eric Anholt wrote: > > I'm going to look at the case I "think" I hit an improvement for and > > dissect _why_, then get back to you. I'll check this again shortly.. (I recall I was testing this with the display lists anyway).. > > I'm chasing my code right now

Re: [Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.

On Mon, 1 Nov 2010 17:00:46 -0400, Andrew Lutomirski wrote: > Out of curiousity, what happened to ACPI_BM_BREAK_EN here: > > https://bugs.freedesktop.org/show_bug.cgi?id=30364 > > On my box, that register is (according to setpci) 0x00, but I'm > testing on an ICH9M and I don't seem to be affecte

Re: [Intel-gfx] [PATCH] drm/i915: Fix the graphics frequency clamping at init and when IPS is active.

On Mon, 1 Nov 2010 14:12:01 -0700, Eric Anholt wrote: > From: Jesse Barnes > - DRM_DEBUG_DRIVER("fmax: %d, fmin: %d, fstart: %d\n", fmax, fmin, > + DRM_ERROR("fmax: %d, fmin: %d, fstart: %d\n", fmax, fmin, >fstart); Error? -Chris -- Chris Wilson, Intel Open Sou

[Intel-gfx] [PATCH] drm/i915: Fix the graphics frequency clamping at init and when IPS is active.

From: Jesse Barnes Part of the issue here was that Eric slipped in a debug hack for testing the i915 IPS code before the intel_ips.c driver had landed. This caused the driver to always use the full range of frequencies, which is only legal when IPS tells us we have the headroom. Once that hack w

Re: [Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.

Out of curiousity, what happened to ACPI_BM_BREAK_EN here: https://bugs.freedesktop.org/show_bug.cgi?id=30364 On my box, that register is (according to setpci) 0x00, but I'm testing on an ICH9M and I don't seem to be affected anyway. --Andy On Mon, Nov 1, 2010 at 4:23 PM, Eric Anholt wrote:

Re: [Intel-gfx] [PATCH] drm/i915: remove debug fmax

On Mon, 1 Nov 2010 16:26:05 -0400 Jesse Barnes wrote: > Accidentally got pushed when we added power monitoring support. We > need IPS to modify this value rather than always setting it to the > max. > > Signed-off-by: Jesse Barnes > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/driv

[Intel-gfx] [PATCH] drm/i915: remove debug fmax

Accidentally got pushed when we added power monitoring support. We need IPS to modify this value rather than always setting it to the max. Signed-off-by: Jesse Barnes diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4954af2..688b51d 100644 --- a/dr

[Intel-gfx] [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

Improves nexuiz performance by about 1% on my system. Signed-off-by: Eric Anholt --- drivers/cpuidle/governors/menu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index f508690..9bb5654 100644 --- a/

[Intel-gfx] [PATCH 3/4] drm/i915: Declare waits on GPU as io waits, to reduce C-state reduction.

Because of this, the C-state governor will consider our process "performance critical" and avoid dropping CPU power during these temporary sleeps. There are two benefits of this: We don't lose our cache contents (whose value is not well reflected in the metrics of the governor), and also don't red

[Intel-gfx] [RFC] Hack to avoid C-state reduction during graphics activity.

This is a series I came up with as a result of KS discussions. The plan was to pin the CPU C state to keep the GPU going as fast as possible while it was active, since there's some relation between the two (we don't know for sure yet, per chipset, whether it's due to latency of DMA writes having t

[Intel-gfx] [PATCH 1/4] sched: Export io_schedule_timeout()

This is the logical partner to the already exported io_schedule() and schedule_timeout(), and will be used by the DRM. Signed-off-by: Eric Anholt --- kernel/sched.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/kernel/sched.c b/kernel/sched.c index aa14a56..ec853f9 100

[Intel-gfx] [PATCH 2/4] Add io_ variants of wait_event() and wait_event_interruptible()

These tell the scheduler that we're waiting on IO, and still "busy". Signed-off-by: Eric Anholt --- include/linux/wait.h | 46 ++ 1 files changed, 46 insertions(+), 0 deletions(-) diff --git a/include/linux/wait.h b/include/linux/wait.h index 3efc9f

Re: [Intel-gfx] intel_prepare_render(intel); unhelpful?

On Mon, 01 Nov 2010 19:52:58 +, Peter Clifton wrote: > On Sun, 2010-10-31 at 20:54 -0700, Eric Anholt wrote: > > > Now, this version of the code has bothered me, since apps that execute > > in one batchbuffer should end up getting overly penalized. See > > intel-throttle-hack of my mesa tree

Re: [Intel-gfx] intel_prepare_render(intel); unhelpful?

On Sun, 2010-10-31 at 20:54 -0700, Eric Anholt wrote: > Now, this version of the code has bothered me, since apps that execute > in one batchbuffer should end up getting overly penalized. See > intel-throttle-hack of my mesa tree for a possible fix. I like it! I still can't quite figure out what

Re: [Intel-gfx] intel_prepare_render(intel); unhelpful?

On Sun, 2010-10-31 at 20:54 -0700, Eric Anholt wrote: > On Sun, 31 Oct 2010 01:15:34 +, Peter Clifton wrote: > > For instance, in intelClear() we call it - AIUI, flushing rendering > > before code execution continues. Nasty ;( > > I don't see flushing in intel_prepare_render() unless you're u

Re: [Intel-gfx] [PATCH 1/5] render: set the surface state base address

After tripping over a few issues with mixing in snb 2D support, I have your patches running and they are proving quite stable. Nice work, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop

[Intel-gfx] do i915 depend on msi?

Hallo, i need to test my netbook with msi disabled but i get fallowing oops: [ 67.097058] [ cut here ] [ 67.097162] kernel BUG at /home/src/linux-2.6/drivers/gpu/drm/i915/i915_gem.c:4157! [ 67.097297] invalid opcode: [#1] SMP [ 67.097380] last sysfs file: /sy

[Intel-gfx] save register range for reg_dumper

Hallo, i trying to make registers dump or snapshot, but it seems to be unsave on my HW, my netboock will just freeze. What register range is actually save to capture? -- Regards, Alexey ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 2/2] support BLT acceleration on gen6

On Mon, 1 Nov 2010 13:23:36 +0800, Zou Nan hai wrote: > support BLT acceleration on gen6 platform. Those patches looked good, so I pushed them on your behalf. Now let's have a look at the render patches and hope they recover the 40x performance loss from the BLT "acceleration". -Chris -- Chri

Re: [Intel-gfx] [PATCH] drm/i915: opregion_setup: iounmap correct address

On Mon, 01 Nov 2010 11:32:22 +0100, Christoph Fritz wrote: > In case of an opregion signature mismatch in intel_opregion_setup(), > iounmap the correct address. Applied to -fixes and tagged for stable. Thanks! -Chris -- Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH] drm/i915: I915_WRITE16 should call writew

Fix the wrong call of writel: I915_WRITE16 should call writew instead of writel. Signed-off-by: Yuanhan Liu --- drivers/gpu/drm/i915/i915_drv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2c2c19

Re: [Intel-gfx] less load less performance

Am Sonntag, den 31.10.2010, 15:07 -0700 schrieb Arjan van de Ven: > On 10/31/2010 9:44 AM, Alexey Fisher wrote: > > Hallo all, > > > > after testing latest intel_drm_next v2.6.36-07547-g100519e on my netbook > > i have seen interesting issue. Standardly started glxgears performs not > > so well, it

[Intel-gfx] [PATCH 5/5] render: use headerless render target write

It is weird that some rendercheck cases only work fine with headerless write. Need to update intel-gen4asm to support headerless write Signed-off-by: Xiang, Haihao --- src/render_program/exa_wm_write.g6a | 10 -- src/render_program/exa_wm_write.g6b |4 +--- 2 files changed, 5 inser

[Intel-gfx] [PATCH 4/5] render: acceleration for composite on Sandybridge

Signed-off-by: Xiang, Haihao --- src/i965_render.c | 686 +++-- 1 files changed, 670 insertions(+), 16 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index 885889e..e2b67c3 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@

[Intel-gfx] [PATCH 3/5] render: fragments for composite on Sandybridge

Signed-off-by: Xiang, Haihao --- src/render_program/Makefile.am | 18 +++ src/render_program/exa_wm_ca.g6a |1 + src/render_program/exa_wm_ca.g6b |4 ++ src/render_program/exa_wm_ca_srcalpha.g6a |1 + src/render_program/exa_wm_ca_

[Intel-gfx] [PATCH 2/5] render: fix send instruction used in sampling fragments

To prepare for composite on Sandybridge Signed-off-by: Xiang, Haihao --- src/render_program/exa_wm_mask_sample_a.g4a|3 ++- src/render_program/exa_wm_mask_sample_a.g4b|3 ++- src/render_program/exa_wm_mask_sample_a.g4b.gen5 |3 ++- src/render_program/exa_wm_mask_sam

[Intel-gfx] [PATCH 1/5] render: set the surface state base address

It is the same as commit 73d4c7d7 Signed-off-by: Xiang, Haihao --- src/i965_render.c | 75 + 1 files changed, 24 insertions(+), 51 deletions(-) diff --git a/src/i965_render.c b/src/i965_render.c index c0c5de4..885889e 100644 --- a/src/i965_r