[Intel-gfx] [PATCH 1/2] drm/i915: Add self-refresh support on Sandybridge

Add the support of memory self-refresh on Sandybridge, which is now support 3 levels of watermarks and the source of the latency values for watermarks has changed. On Sandybridge, the LP0 WM value is not hardcoded any more. All the latency value is now should be extracted from MCHBAR SSKPD registe

[Intel-gfx] [PATCH 2/2] drm/i915: Add frame buffer compression on Sandybridge

Add frame buffer compression on Sandybridge. The method is similar to Ironlake, except that two new registers of type GTTMMADR must be written with the right fence info. Signed-off-by: Yuanhan Liu --- drivers/gpu/drm/i915/i915_dma.c |4 ++-- drivers/gpu/drm/i915/i915_drv.c |1 +

[Intel-gfx] [PATCH 0/2] drm/i915: enable CxSR and FBC on Sandybridge

Hi, This two patches enable self refresh and frame buffer compression on Sandybridge. FYI, with my test, enable CxSR would save about 0.7W, while enable FBC would save about 0.1~0.2W. Thanks. Yuanhan Liu -- Yuanhan Liu (2): drm/i915: Add self-refresh support on Sandybridge drm/i915: Add fr

Re: [Intel-gfx] pipe control notify removed?

Yeah, I also met this issue, and bisection point to this as well :) 32402 19:05:15 cri hig ch...@chris-wilson.co.uk shuang...@intel.com NEW [piketon -next bisected] Many tests make GPU hang and reset Thanks --Shuang On 2

[Intel-gfx] pipe control notify removed?

Chris, just notice you removed pipe control notify entirely on -next, that seems wrong to me. In Ironlake time, we've seen interrupt stall issue with user interrupt, and be warned user interrupt is deprecated, so we moved on to use pipe control notify, although there's a workaround later covered t

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

On 2010.12.14 19:13:22 +0100, Daniel Vetter wrote: > On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote: > > It appears Sandybridge PIPE_CONTROL write out buffer need > > to be set as cached, currently LLC cached, in order to read > > back correct counter. Otherwise I can always be possibl

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

On 2010.12.14 21:47:45 +, Chris Wilson wrote: > On Tue, 14 Dec 2010 20:59:09 +, david may > wrote: > > Hello Eric, > > > > Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > > > > > Why don't we just keep all of our BOs LLC cached? This was supposed to > > > be a big win of the new c

Re: [Intel-gfx] drm/i915: unconditionally unlock panel regs

On 14/12/10 12:17 -0800, Jesse Barnes wrote: > In the panel_on function we skip everything if the panel is already > powered up. However, if it's powered up but not unlocked, subsequent > register writes may fail. > > So unlock the regs regardless of the panel state to allow other mode > setting

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

On Tue, 14 Dec 2010 20:59:09 +, david may wrote: > Hello Eric, > > Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > > > Why don't we just keep all of our BOs LLC cached? This was supposed to > > be a big win of the new chipset, as it means we don't need to clflush. > > Ohh,the implicat

Re: [Intel-gfx] [PATCH] drm/i915: unconditionally unlock panel regs

On Tue, 14 Dec 2010 20:45:14 + Chris Wilson wrote: > On Tue, 14 Dec 2010 12:17:59 -0800, Jesse Barnes > wrote: > > In the panel_on function we skip everything if the panel is already > > powered up. However, if it's powered up but not unlocked, subsequent > > register writes may fail. > >

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

Hello Eric, Tuesday, December 14, 2010, 5:58:58 PM, you wrote: > On Tue, 14 Dec 2010 12:55:59 +0800, Zhenyu Wang > wrote: >> It appears Sandybridge PIPE_CONTROL write out buffer need >> to be set as cached, currently LLC cached, in order to read >> back correct counter. Otherwise I can always b

Re: [Intel-gfx] General Purpose Programming GPU/(G)MCH

On 2010-12-14 10:42+0100 Clemens Eisserer wrote: .. they start call gpu inside GMCH since 965 ). I wold be great full for some more links to decumentation and codes. I guess just because the term "GPU" was uncommon before. Fact is, gen3 contains programmable pixel shaders. However if it isn'

Re: [Intel-gfx] [PATCH] drm/i915: unconditionally unlock panel regs

On Tue, 14 Dec 2010 12:17:59 -0800, Jesse Barnes wrote: > In the panel_on function we skip everything if the panel is already > powered up. However, if it's powered up but not unlocked, subsequent > register writes may fail. > > So unlock the regs regardless of the panel state to allow other mo

[Intel-gfx] [PATCH] drm/i915: unconditionally unlock panel regs

In the panel_on function we skip everything if the panel is already powered up. However, if it's powered up but not unlocked, subsequent register writes may fail. So unlock the regs regardless of the panel state to allow other mode setting programming to occur normally. [Still waiting to hear fr

[Intel-gfx] [PATCH] i915: Modify for pineview clock source

The i915 driver normally assumes the video bios has configured several of the LVDS panel registers, and it just inherits the values. If the vbios has not run, several of these will need to be setup. intel_bios.c: default clock source selection on pineview to use the SSC source. If these are no

[Intel-gfx] [PATCH] i915: Modify for pineview lvds sync polarity

The i915 driver normally assumes the video bios has configured several of the LVDS panel registers, and it just inherits the values. If the vbios has not run, several of these will need to be setup. intel_display.c: ensures the sync polarity to the panel is correct and issues a message if the d

Re: [Intel-gfx] of the LVDS panel registers, and it just inherits the values. If the

Sorry, bad patch email. Working on it... bryan. On Tue, Dec 14, 2010 at 11:23 AM, wrote: > intel_display.c: ensures the sync polarity to the panel is correct > and issues a message if the driver changes it. > > If these are not correct then although the panel looks ok, output from an > HDMI >

[Intel-gfx] of the LVDS panel registers, and it just inherits the values. If the

intel_display.c: ensures the sync polarity to the panel is correct and issues a message if the driver changes it. If these are not correct then although the panel looks ok, output from an HDMI encoder (eg, Chrontel CH7036) will be incorrect. Signed-off-by: Mark Hayter Index: drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH] drm/i915: Set the required VFMUNIT clock gating disable on Ironlake.

On Tue, 14 Dec 2010 10:06:46 -0800, Eric Anholt wrote: > It's required by the specs, but we don't know why. Let's not find out > why. Any feel at all for the level of impact of not disabling power gating of the VFM unit? Random hang? Incorrect output? I'm not even sure what the VFM unit is. -Chr

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote: > It appears Sandybridge PIPE_CONTROL write out buffer need > to be set as cached, currently LLC cached, in order to read > back correct counter. Otherwise I can always be possible to > get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTRO

[Intel-gfx] [PATCH] drm/i915: Set the required VFMUNIT clock gating disable on Ironlake.

It's required by the specs, but we don't know why. Let's not find out why. Signed-off-by: Eric Anholt --- drivers/gpu/drm/i915/i915_reg.h |3 +++ drivers/gpu/drm/i915/intel_display.c |2 ++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg

Re: [Intel-gfx] patches for occlusion query fix on sandybridge

On Tue, 14 Dec 2010 12:55:59 +0800, Zhenyu Wang wrote: > It appears Sandybridge PIPE_CONTROL write out buffer need > to be set as cached, currently LLC cached, in order to read > back correct counter. Otherwise I can always be possible to > get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL wri

Re: [Intel-gfx] General Purpose Programming GPU/(G)MCH

Im doing it for fun and education purpose. I programed with OpenGL and more with CUDA and its PTX ( in my work ), tryied Close To Metal etc. but now i wanted to do it on weary low level usings ports programming directly EUs/GPU to understand better mechanizms to improve speed and algorithm and f

Re: [Intel-gfx] General Purpose Programming GPU/(G)MCH

> I wold be great full for some more links to decumentation and codes. My advice would be to use OpenGL and the ARB extensions for pixel programs. I've played a bit with pixel shaders before, using NVidia's CG toolkit which makes it possible to compile Cg/GLSL to ARB extension's assembler-style c

Re: [Intel-gfx] General Purpose Programming GPU/(G)MCH

> .. they start call gpu inside GMCH since 965 ). I wold be great full for > some more links to decumentation and > codes. I guess just because the term "GPU" was uncommon before. Fact is, gen3 contains programmable pixel shaders. However if it isn't just for fun I discourage from going that rou

Re: [Intel-gfx] [PATCH] intel: new interface for cached bo create

On Tue, 14 Dec 2010 12:56:01 +0800, Zhenyu Wang wrote: > This is required for special bo like PIPE_CONTROL store DW buffer > used in occlusion query. You also need to mark the buffer as non-reusable so that it is not cached on release. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] ignore cached memory flag in i965_write_entry()?

On Tue, 14 Dec 2010 13:02:50 +0800, Zhenyu Wang wrote: > On 2010.12.14 11:03:53 +0800, Zhenyu Wang wrote: > > > > Looks from a6963596a13e62f8e65b1cf3403a330ff2db407c, setting > > GTT entry on i965-ish totally ignored cached memory flag? > > That might break r/w consistent for pages like hw status