Speed boost disabling RCC clock gating ECO

Speed boost disabling RCC clock gating ECO

[Peter Clifton]

Hi guys,

Just a note on a data-point I found here:

sudo intel_reg_read 0x21D0
[sudo] password for pcjc2: 
0x21D0 : 0x307

sudo intel_reg_write 0x21D0 0x1000207
Value before: 0x307
Value after: 0x207


This boosted FPS of my displaylist frame benchmark from 35fps to 37fps.

This was clearing bit 8 of ECOSKPD, which is controlling the following
ECO:

Clock gating for the RCC (Disable one clock gate cell)


Any chance someone knows why the ECO is in place, or whether it is
dangerous to disable?

I also noticed that the specs for bit 12 and 9 (working around a CLIP
bug) are set in an invalid state according to the G45 PRM.

I have bit 12=0, bit9=1

This does match the expected default setting though.. is there a typo in
the PRM (Vol1a, P.322.) mixing bits 9 and 12 around in the table?


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

Re: Speed boost disabling RCC clock gating ECO

[Peter Clifton]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Sat, 2010-10-30 at 03:34 +0100, Peter Clifton wrote:

> sudo intel_reg_write 0x21D0 0x1000207
> Value before: 0x307
> Value after: 0x207
> 
> 
> This boosted FPS of my displaylist frame benchmark from 35fps to 37fps.
> 
> This was clearing bit 8 of ECOSKPD, which is controlling the following
> ECO:
> 
> Clock gating for the RCC (Disable one clock gate cell)

And the obligatory profile.. (promise, this is the last one I'll send
before someone comments on the others. It is 3:50AM here!)

I'm not sure quite how repeatable the profiles are, but this is the same
frame (in a displaylist), with same test conditions. (CPU forced to top
speed and out of C-states with two busy-loop programs to keep the cores
busy). The profile does look somewhat different.

Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

[-- Attachment #2: gpu_profile3.png --]
[-- Type: image/png, Size: 27298 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Speed boost disabling RCC clock gating ECO

[Chris Wilson]

On Sat, 30 Oct 2010 03:34:37 +0100, Peter Clifton <pcjc2@cam.ac.uk> wrote:
> Hi guys,
> 
> Just a note on a data-point I found here:
> 
> sudo intel_reg_read 0x21D0
> [sudo] password for pcjc2: 
> 0x21D0 : 0x307
> 
> sudo intel_reg_write 0x21D0 0x1000207
> Value before: 0x307
> Value after: 0x207
> 
> 
> This boosted FPS of my displaylist frame benchmark from 35fps to 37fps.
> 
> This was clearing bit 8 of ECOSKPD, which is controlling the following
> ECO:
> 
> Clock gating for the RCC (Disable one clock gate cell)

Bizarre, here that's documented as only being defined for Crestline. Maybe
they meant mobile parts? The impact would be to disable some powersaving
and maybe risk exceeding its thermal envelope.

> Any chance someone knows why the ECO is in place, or whether it is
> dangerous to disable?

They look fairly benign. A couple change the behaviour significantly that
could result in undefined behaviour if the driver exceeded the new limits.

> I also noticed that the specs for bit 12 and 9 (working around a CLIP
> bug) are set in an invalid state according to the G45 PRM.
> 
> I have bit 12=0, bit9=1

Well the good news is that those are intended to workaround silicon bugs
in Broadwater (965G) and Crestline (965GM).

> This does match the expected default setting though.. is there a typo in
> the PRM (Vol1a, P.322.) mixing bits 9 and 12 around in the table?

The bad news is that those were copied verbatim from the original. And
(1,0) is indeed supposed to be invalid. Aren't unexplained magic bits
exciting?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre