[PROJ] Overclocking the Adreno GPU on Snapdragon Devices

Search This thread
By:
Advanced…
jlevy73

jlevy73

Senior Member
Nov 8, 2009
9,470
1,302
Los Angeles
Geniusdog254 said:
I just woke back up. I guess I will remove the EBI1 overclock since I'm not sure what it does. I'm also not sure what increasing the GPU memory will do, but it's worth a shot.

I had noticed EBI1 is being set to 0 whenever it's diabled, and then setting it back at the time it's enabled. I'm gunna go back through and try to find another setting for the grp clock & a setting for the imem clock.
Click to expand...
Click to collapse

Be curious to see what increasing the memory of the GPU will do. I do recall when coohlbro came up with the 21mb hack. I took this straight from the OP of that thread (because I am too tired to paraphrase it):

This time, my RAM hack expands memory by 21MB total from the stock kernel. And this time, no camera PMEM is taken away! This is all thanks to the incrediblec kernel source released by HTC giving me some insight.

This is what I did, starting from the 8MB RAM hack:
- Expanded EBI1_BANK0 by 8MB because the incrediblec source said I could
- Moved 5MB GPU memory from EBI1_BANK0 to SMI
- Created extra memory bank in EBI1_BANK0 totalling 13MB
- Added 8MB camera PMEM back into SMI, and re-enabled camera PMEM

Version 2:
- Eliminated third memory bank in EBI1_BANK0 and added that memory into the first memory bank

As far as I know it's not possible to create a memory bank in the SMI and live to tell the tale, so that's why we're squeezing the 8MB of camera PMEM in there. In total, this adds 21MB of RAM from stock cm-kernel with seemingly no compromises.

The zImage is meant to be a proof of concept and only contains this tweak on top of normal cm-kernel. I don't suggest using this zImage for long, as it doesn't contain any "extras," and the regular custom kernels with all the extra features/optimizations will probably incorporate this soon.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
Changing the RAM tables won't be too difficult. I'm gunna play with some values here in a minute & try it out. I don't have my Nexus with me so I won't be able to test it for the next hour or two, but I will be able to go through some source right now.

As if we needed more proof as to how much we need is OC, look here: http://bit.ly/csSIzp

Our chip shouldn't struggle to come close to that at all, yet it does.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
I'm building a kernel right now that should return all the clock values for all the graphics related stuff. It won't tell me where it's set, but I can try and change the values elsewhere if I have to and hope they stick.

To get the current frequencies I'm using the pr_info method called every time kgsl is enabled. Here is the code:

Code: 
        .... kgsl stuff up here ....
        // this *should* get the clock rate & print it in the kernel log
	pr_info("kgsl: grp_clock at ", clk_get_rate(kgsl_driver.grp_clk), "hz");
	pr_info("kgsl: imem_clock at ", clk_get_rate(kgsl_driver.imem_clk), "hz");
	pr_info("kgsl: ebi1_clock at ", clk_get_rate(kgsl_driver.ebi1_clk), "hz");	
        .... more kgsl stuff down here ....

This should return all the clock values for us, but then my C experience is nonexistant, so correct me if I made some obvious glaring mistake please.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
Wow, am I the only one who cares about this at this point? :p ;)

The debug code was screwed up the first time. I changed it to this:

Code:

Which managed to return this in dmesg:

Code: 
<6>[   70.681793] kgsl: grp_clock= 256000000
<6>[   70.682464] kgsl: imem_clock= 256000000
<6>[   70.683441] kgsl: ebi1_clock= 128000000

So that tells us that the graphics clock and the memory clock are at 256Mhz. It may be a coincidence that the memory clock and the GPU clock are set the same, but more likely is that they are set the same so they can keep up with each other. For instance the memory bus isn't feeding the GPU more than it can handle & the GPU isn't trying to get more data than it can be fed by the memory bus. Just a theory though.
 
goffmj

goffmj

Senior Member
Mar 7, 2010
155
23
Minneapolis
Geniusdog254 said:
Wow, am I the only one who cares about this at this point? :p ;)

The debug code was screwed up the first time. I changed it to this:

Code:

Which managed to return this in dmesg:

Code: 
<6>[   70.681793] kgsl: grp_clock= 256000000
<6>[   70.682464] kgsl: imem_clock= 256000000
<6>[   70.683441] kgsl: ebi1_clock= 128000000

So that tells us that the graphics clock and the memory clock are at 256Mhz. It may be a coincidence that the memory clock and the GPU clock are set the same, but more likely is that they are set the same so they can keep up with each other. For instance the memory bus isn't feeding the GPU more than it can handle & the GPU isn't trying to get more data than it can be fed by the memory bus. Just a theory though.
Click to expand...
Click to collapse

Awesome work.

Ok, could you please do the Evo world a favor? Could you bring this post over to the GPU project thread in the Evo section? Perhaps someone could find out what the Evo is clocked at.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
goffmj said:
Awesome work.

Ok, could you please do the Evo world a favor? Could you bring this post over to the GPU project thread in the Evo section? Perhaps someone could find out what the Evo is clocked at.
Click to expand...
Click to collapse

I'm pretty sure the Evo is clocked the same, but I'm not sure. If I could get my Evo kernel to build, then I would try it myself. But the danged hacked source won't build on my machine, so I'm waiting for the real Evo source drop before I do any real work on mine.

EDIT: Also, I just tried changing the clock speeds before the kernel enables each the GPU & the memory bus clock, but when it goes and enables the clock, they're set back down to 256mhz. I'll try a version with the change being made after the clocks are enabled and see if that changes anything.
 
Last edited:
fstluxe

fstluxe

Senior Member
Sep 15, 2009
226
13
New York
are you doing that by chaning the freq or adding this at the end of the freq something like this hexa +0x40);
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
fstluxe said:
are you doing that by chaning the freq or adding this at the end of the freq something like this hexa +0x40);
Click to expand...
Click to collapse

Well I'm trying to set it the same way that the stock kernel sets the ebi1 clock. The stock code looks like "clk_set_rate(kgsl_driver.ebi1_clk, 128000000);"

So to try and set the other 2 clocks I used:

Code: 
	int imem_grp_clk = 384000000;

        //other code here
	clk_set_rate(kgsl_driver.imem_clk, imem_grp_clk);

        //other code here
	clk_set_rate(kgsl_driver.grp_clk, imem_grp_clk);

Should I be doing it another way? Like I already said, my C experience is almost nonexistant, so I'm probably doing it wrong. I know that in the original MSM7500 chips they used writel and then hex values like you showed, but that's over my head, so I don't know how to do it. If you tell me what code to put or how to do that, then I will try it and let you know.
 
babijoee

babijoee

Retired Forum Moderator
Dec 7, 2008
1,548
163
Melbourne
keep up the good work. When i see galaxy S get 50-60fps in neocore it makes me sad when n1 get 25-30fps :(
 
midnightslide

midnightslide

Senior Member
Jun 17, 2007
173
12
Southern California
Wow.. amazing work so far. This gets me really excited to see what is in store for the Android community.. as well as what these phones are really capable of. Keep up the great work!!
 
jlevy73

jlevy73

Senior Member
Nov 8, 2009
9,470
1,302
Los Angeles
babijoee said:
keep up the good work. When i see galaxy S get 50-60fps in neocore it makes me sad when n1 get 25-30fps :(
Click to expand...
Click to collapse

Two very different chips though. The samsung uses their proprietary hummingbird chipset while the N1 uses the Snapdragon. The snapdragon outperforms hummingbird for cpu related functions but hummingbird is excellent for gpu related tasks.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
jlevy73 said:
Two very different chips though. The samsung uses their proprietary hummingbird chipset while the N1 uses the Snapdragon. The snapdragon outperforms hummingbird for cpu related functions but hummingbird is excellent for gpu related tasks.
Click to expand...
Click to collapse

Well said. The Snapdragon has excellent CPU performance for a mobile, but it uses an outdated AMD z430 GPU which has been rebranded as an Adreno 200 chip. I'm looking for a datasheet for it that may help me with setting the clocks or at least tell me more about it, but I've yet to find one. If you find one, give me a shout please :)

Also, setting the clock before or after the clocks are enabled makes no difference, they're instantly reset back to what they wore, or they're just not being changed at all. I need to find a way to set them in a way that sticks. Clk_set_rate has no effect, and clk_set_rate_sticky isn't defined in clk.h and yet it's called in board-mahimahi.c.

I will try the clk_set_rate_sticky call in just a moment. If it doesn't work then I will try some variations of writel as called in the original overclock source.
 
jlevy73

jlevy73

Senior Member
Nov 8, 2009
9,470
1,302
Los Angeles
Just spent 20 minutes looking for a spec sheet on the Andreno and came up with nothing. Will keep looking though it has to be out there somewhere
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
dogiedogie said:
It might be worth looking at it under the AMD derivative, I too couldnt find anything about it when I looked a while ago.
Click to expand...
Click to collapse

jlevy73 said:
Just spent 20 minutes looking for a spec sheet on the Andreno and came up with nothing. Will keep looking though it has to be out there somewhere
Click to expand...
Click to collapse

Yeah that's my problem too. There isn't ANYTHING on it. There are very few Qualcomm datasheets actually out there. There are some for most of the old MSM chipsets, but none of their latest generation stuff (Snapdragon, MSM7227, etc) is available at least as far as I can find.

Another thing to consider is it may be in with the Snapdragon pages, which as far as I know haven't been publicly leaked either. Damn NDAs.

And now that I look, I can't find the method I talked about in my last post. I can't find where it was used and I don't think it was clk_set_rate_sticky either. Thats what I get for working on it at 1AM and then stopping in the middle until 4PM the next day. My bad :eek:

Maybe it was clk_set_rate_locked...

EDIT BINGO! Damn I knew it was there somewhere. In arch/arm/mach-msm/clock.c:

Code: 
	/* gross hack to set axi clk rate when turning on uartdm clock */
	if (id == UART1DM_CLK && axi_clk)
		clk_set_rate_locked(axi_clk, 128000000);
	return msm_proc_comm(PCOM_CLKCTL_RPC_ENABLE, &id, NULL);
And of course gross hacks are exactly what all my C code is, so I'll try that method for the GRP clock right quick.
 
Last edited:
jlevy73

jlevy73

Senior Member
Nov 8, 2009
9,470
1,302
Los Angeles
Geniusdog254 said:
Yeah that's my problem too. There isn't ANYTHING on it. There are very few Qualcomm datasheets actually out there. There are some for most of the old MSM chipsets, but none of their latest generation stuff (Snapdragon, MSM7227, etc) is available at least as far as I can find.

Another thing to consider is it may be in with the Snapdragon pages, which as far as I know haven't been publicly leaked either. Damn NDAs.

And now that I look, I can't find the method I talked about in my last post. I can't find where it was used and I don't think it was clk_set_rate_sticky either. Thats what I get for working on it at 1AM and then stopping in the middle until 4PM the next day. My bad :eek:

Maybe it was clk_set_rate_locked...

EDIT BINGO! Damn I knew it was there somewhere. In arch/arm/mach-msm/clock.c:

Code: 
	/* gross hack to set axi clk rate when turning on uartdm clock */
	if (id == UART1DM_CLK && axi_clk)
		clk_set_rate_locked(axi_clk, 128000000);
	return msm_proc_comm(PCOM_CLKCTL_RPC_ENABLE, &id, NULL);
And of course gross hacks are exactly what all my C code is, so I'll try that method for the GRP clock right quick.
Click to expand...
Click to collapse

Nice find. Let's see how that works out.
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
jlevy73 said:
Nice find. Let's see how that works out.
Click to expand...
Click to collapse

Not very well. That method isn't defined in clk.h as I said earlier, instead it's a private method in clock.c, so it won't compile if I call it straight from kgsl, but if I copy the declaration to clk.h then it breaks clock.c.

Give me a second. Gunna try to copy it to kgsl.c, if that doesn't work then I'll try and actually set the clock in clock.c.
 
jlevy73

jlevy73

Senior Member
Nov 8, 2009
9,470
1,302
Los Angeles
Maybe this is being looked at the wrong way. Open GL seems to be the limiting factor in terms of graphics rendering, especially ones in 3D. So even if the GPU was overclocked I wonder if limitations in Open GL would prohibit seeing any real world gains. I just found a site that discussed Open GL and how to manipulate it to improve graphics rendering. Also Open GL is now up to 4.0 as opposed to 2.0 used with the Nexus One. I am going to see if I can make any sense of the programming language being used as it involved code that looks greek to me :)
 
Geniusdog254

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
jlevy73 said:
Maybe this is being looked at the wrong way. Open GL seems to be the limiting factor in terms of graphics rendering, especially ones in 3D. So even if the GPU was overclocked I wonder if limitations in Open GL would prohibit seeing any real world gains. I just found a site that discussed Open GL and how to manipulate it to improve graphics rendering. Also Open GL is now up to 4.0 as opposed to 2.0 used with the Nexus One. I am going to see if I can make any sense of the programming language being used as it involved code that looks greek to me :)
Click to expand...
Click to collapse

Thats true there could definitely be improvement on the GL end of things here. That stuff is WAY over my head though.

It seems most of the HTC phones with Qualcomm chipsets are limited there, sloppy coding, or whatever it may be. But at the same time, if the chip can run through the inefficient code faster, then it will still improve things. Think of it like this:

If you're running on a flat tire at 5mph, it sucks and obviously would improve drastically for the same energy if you aired the tire up. BUT, if you just put more energy into the system, you'll still go faster, just not as fast as you could with a full tire.

If that makes any sense ;)
 
You must log in or register to reply here.

Similar threads

P
[Kernel] [2.6.34/2.6.35] OCed - UVed: -1.113Ghz
Replies
5K
Views
677K
P
pershoot
babijoee
[PROJ] Improve/Porting Adreno GPU drivers on Snapdragon Devices
Replies
312
Views
81K
Dany0
Dany0
imfloflo
[NIGHTLY] [ROM] [GWK74] CyanogenMod 7 for vendor Passion (HTC Nexus One) - KANG
Replies
23K
Views
4M
V
Verrocio
enomther
  • Locked
[ROM] Enomther's TheOfficial Nexus1 - v2.14.4 - 11/26/2010
Replies
8K
Views
2M
willverduzco
willverduzco
eViL D:
[ROM] eViL's NXSense v.1.26 - (F)The (I)Gravy (N)Train [11/04/10]
Replies
9K
Views
1M
D
drewzee

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 25
    FeraVolt
    FeraVolt
    Hey Dev! Make those Snapdragons fly!

    A little into:
    Hello Nexus One brotha's) I'm Fera, ROM/Kernel developer from neighbour SonyXperia X10 forum. I'm 20 years old hungry student, studying electronic engineering in Istanbul. I develop android stuff for 2 years. Why I write here? Because I'd like to help you and share a bit of my experience with you guys. Open Source rules! :highfive: Since my and your device have similar boards (qsd8k), the hacks listed here have to work despite different kernel versions things are pretty same on both devices. My kernel development is HERE. Now..enough for drama, have good music, tighten your belts, sit back and relax - we're going to fly at the speed of light :D..

    Hack:
    Ok. It's quite simple actually.
    Overclocking GPU core itself is not possible at this moment but we can overclock it's bus.
    In kernel sources we have acpuclock-8x50.c file. Inside it he will see actual CPU freq. table and misc hw stuff.
    Default freq. table for qsd8k is:
    PHP: 
    	{ 0, 19200, ACPU_PLL_TCXO, 0, 0, 0, 0, 14000, 0, 0, 1000},
	{ 0, 128000, ACPU_PLL_1, 1, 5, 0, 0, 14000, 2, 0, 1000},
	{ 1, 245760, ACPU_PLL_0, 4, 0, 0, 0, 29000, 0, 0, 1000},
	{ 1, 384000, ACPU_PLL_3, 0, 0, 0, 0, 58000, 1, 0xA, 1000},
	{ 0, 422400, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xB, 1000},
	{ 0, 460800, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xC, 1000},
	{ 0, 499200, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xD, 1025},
	{ 0, 537600, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xE, 1050},
	{ 1, 576000, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xF, 1050},
	{ 0, 614400, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x10, 1075},
	{ 0, 652800, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x11, 1100},
	{ 0, 691200, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x12, 1125},
	{ 0, 729600, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x13, 1150},
	{ 1, 768000, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x14, 1150},
	{ 0, 806400, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x15, 1175},
	{ 0, 844800, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x16, 1200},
	{ 0, 883200, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x17, 1225},
	{ 0, 921600, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x18, 1275},
	{ 0, 960000, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x19, 1275},
	{ 1, 998400, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x1A, 1300},
	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},

    Little theory lesson:
    • 1/0 - means that this clk ladder is enabled/disabled
    • 998400 - Actual ladder freq. in Khz
    • ACPU_PLL_3, 0, 0, 0, 0 - AXI/PLL macros, adresses
    • 128000 - AXI freq. in Khz
    • 0/1/2 - Init adresses
    • 0x1A - Step raw code for CPU
    • 1300 - Voltage of freq. step in mV

    So what to do. We see that we have 128000 freq. set as 0 (disabled) for global access and reserved for PLL_1 which is adressed to 2. May sound childish, but this actually means that this line is used for Adreno200 clock. We simply change it to 192000Khz. Overclocking to higher values makes devices unstable.
    The ready line will be look as:
    PHP: 
    { 0, 192000, ACPU_PLL_1, 1, 5, 0, 0, 14000, 2, 0, 1000 },

    But it's not all. Now we have to update AXI frequencies.. How do we do that. Search for this function in same file:
    Code: 
    unsigned long clk_get_max_axi_khz(void)
{
	return 128000;
}
EXPORT_SYMBOL(clk_get_max_axi_khz);
    and set it to 192000.

    Now we have to update all CPU freq table with overclocked axi bus values which could be stable.. At this point I spent monthes of testing and finally came up to stable things. I will just paste here my table which also includes CPU undervolt.
    Here it is:
    PHP: 
    	{ 0, 19200, ACPU_PLL_TCXO, 0, 0, 0, 0, 14000, 0, 0, 975 },
	{ 0, 192000, ACPU_PLL_1, 1, 5, 0, 0, 14000, 2, 0, 975 },
	{ 1, 245760, ACPU_PLL_0, 4, 0, 0, 0, 29000, 0, 0, 975 },
	{ 1, 384000, ACPU_PLL_3, 0, 0, 0, 0, 58000, 1, 0xA, 975 },
	{ 0, 422400, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xB, 975 },
	{ 0, 460800, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xC, 975 },
	{ 0, 499200, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xD, 975 },
	{ 0, 537600, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xE, 975 },
	{ 1, 576000, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0xF, 1000 },
	{ 0, 614400, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x10, 1025 },
	{ 0, 652800, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x11, 1050 },
	{ 0, 691200, ACPU_PLL_3, 0, 0, 0, 0, 117000, 1, 0x12, 1075 },
	{ 0, 729600, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x13, 1075 },
	{ 1, 768000, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x14, 1100 },
	{ 0, 806400, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x15, 1175 },
	{ 0, 844800, ACPU_PLL_3, 0, 0, 0, 0, 128000, 1, 0x16, 1200 },
	{ 0, 883200, ACPU_PLL_3, 0, 0, 0, 0, 160000, 1, 0x17, 1225 },
	{ 0, 921600, ACPU_PLL_3, 0, 0, 0, 0, 160000, 1, 0x18, 1275 },
	{ 0, 960000, ACPU_PLL_3, 0, 0, 0, 0, 160000, 1, 0x19, 1275 },
	{ 1, 998400, ACPU_PLL_3, 0, 0, 0, 0, 160000, 1, 0x1A, 1275 },
	{ 0, 1036800, ACPU_PLL_3, 0, 0, 0, 0, 160000, 1, 0x1B, 1300 },
	{ 0, 1075200, ACPU_PLL_3, 0, 0, 0, 0, 192000, 1, 0x1C, 1325 },
	{ 1, 1113600, ACPU_PLL_3, 0, 0, 0, 0, 192000, 1, 0x1D, 1325 },
	{ 0, 1152000, ACPU_PLL_3, 0, 0, 0, 0, 192000, 1, 0x1E, 1325 },
	{ 1, 1190400, ACPU_PLL_3, 0, 0, 0, 0, 192000, 1, 0x1F, 1350 },
	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
    This is how my table looks after GPU/CPU overclock/undervolt and hard testings. I find theese values solid stable and best at performance. As you may notice, overclocked axi frequency is enabled on higher CPU clock steps. This means that proper axi overclock will be enabled when CPU runs on 1113Mhz and higher, so to enable all this things you have to use overclocked CPU table.

    Now open your board-****.c file.
    If you use old KGSL drivers, search for struct kgsl_platform_data kgsl_pdata function. In function structure you will see this:
    Code: 
    .high_axi_3d = 128000,
    Set value to 192000.

    If you use new KGSL drivers then search for struct kgsl_device_platform_data kgsl_3d0_pdata. You will see:
    PHP: 
    	.pwrlevel = {
			{
				.gpu_freq = 0,
				.bus_freq = 128000000,
			},
    Set value to 192000000

    In the end we have undervolted and overclocked (1.2Ghz) CPU and overclocked GPU. Saying again..Overclocking bus higher than 192Khz is realy bad idea..

    When you're done, build your kernel with enabled debugging (CONFIG_DEBUG_KERNEL=y) and then add this script to mount debug sysfs dir. in init.d or anywhere else on auostart:
    Code: 
    #!/system/bin/sh
### FeraLab ###
mount -t debugfs debugfs /sys/kernel/debug
echo 0 > /sys/kernel/debug/msm_fb/0/vsync_enable

    When system runs check out /sys/kernel/debug/clk_rate folder (If you can't see this folder the your init.d support is not working properly..put script somewhere else). You will have to see reports:
    • gp_clk - 192000000
    • grp_3d_clk - 256000000
    • imem_clk - 256000000

    Bingo! :silly:
    If you like this - feed me :D
    View
    5
    Geniusdog254
    Geniusdog254
    INFO:
    Let me save you the time of reading all this. In it's current form, this is impossible. An inside connect at Qualcomm has told us we can't change the GPU clock from userland or kernel. That mean's we're screwed basically. Here is the post by Jack_R1:
    Checked, as promised. Bad news. If I sum it up in one sentence - GPU overclock w/o touching the rest of the system is plain impossible, and GPU overclock while trying to play with the whole system is most probably still impossible (pending further deeper check), and it's definitely impossible for anyone that doesn't have the clock diagram, which is NDA, thus won't be available. The reason isn't software, and don't ask, what it is - I won't give direct explanations.

    I've written a long post with some explanations of clock networks, to educate those that want to learn and prevent some of big mistakes that I've seen along this thread, and it's pending approval, since I don't want to accidentally spill more than I can share. I hope it gets approved and I'll post it. It should give some more insight.

    The only good news is - global overclocking that affects 1GHz CPU clock will affect GPU too.
    Click to expand...
    Click to collapse

    I'm sure we all heard about being able to overclock the GPU on some of the old MSM devices, but the Snapdragon handles the graphics chip in a different way. The goal of this thread is to try and overclock the GPU on Snapdragon devices as well.

    There is nothing GPU related in acpuclock-scorpion.c at least for setting clock speed as far as I can tell.

    In board-mahimahi.c there is some kgsl init code, but so far as I can tell it isn't setting the clock there, instead it seems to be pointing to PWR_RAIL_GRP_CLK to set the clock. It defines the variable in board-mahimahi.c but I'm not sure where that variable is set, since it doesn't seem to be in any of the other board files as far as I can tell. I could be completely off here too though.

    In drivers/video/msm/gpu/kgsl/kgsl.c there is a method called kgsl_clk_enable that seems to be called whenever the GPU is enabled. It looks like this:

    Code: 
    /* the hw and clk enable/disable funcs must be either called from softirq or
 * with mutex held */
static void kgsl_clk_enable(void)
{
	//clk_set_rate(kgsl_driver.ebi1_clk, 128000000);
	clk_set_rate(kgsl_driver.ebi1_clk, 245000000);
	clk_enable(kgsl_driver.imem_clk);
	clk_enable(kgsl_driver.grp_clk);
}

    The line that's been commented out is the original value, I replaced it with my value on the line below it in a failed attempt to overclock it. Probably a stupid effort on my part, I doubt it's that simple, but it was worth a shot.

    According to the clk.h files in the standard linux kernel, clk_set_rate is obviously a method to set the clock rate. The first variable is a struct that tells it which clock to set, and the second variable is a long value that is the rate you want it set at. Is it setting the right clock there for Snapdragon chips? Or is it only the clock for older chips? Actually I've looked again, the kgsl files are ONLY for the newer Qualcomm chips, the QSD8x50 Snapdragons & the midrange MSM7x27 series that replaced the old MSM7x00a chips like in the Dream & Magic. At least thats the way it seems to me judging from what Qualcomm & AMD have written in the source.

    I'm in way over my head with this source, I'm but a lowly Java dev ;) , but I really wanna solve this. Can anyone with a little more experience than me throw in a little more info? Sorry if it doesn't make much sense, if it isn't clear just ask me & I'll try to explain a little more.

    Regards,
    Jesse C


    EDIT: Okay I did a little more digging and those kgsl settings should work for QSD8x50 chips. In the config file, under Drivers, Graphics Support, it allows you to enable 3D accelleration for QSD8x50 & MSM7x27 chips. The tag for that is CONFIG_MSM_KGSL_MMU. If you check in kgsl.c it checks to see if that is enabled in the config, and if it is then it compiles and uses kgsl.c & all of the kgsl code. That tells me that the clock is either not being set, or the wrong clock is being set. I'm adding some debug code right now so I can see in dmesg what code is actually being run.

    EDIT 2: Another status update. Adding the debug code showed that it is setting the clock at my level whenever the kgsl initializes. Also, as IntersectRaven pointed out, clocks.h in arch/arm/mach-msm nicely lays out what each clock is:

    Code: 
    grp_clock = Graphics clock
ebi1_clock = External Bus Interface 1 clock
imem_clock = Internal Graphics Memory clock

    If you want to add your own debug code to it, calling the method "pr_info" and passing it a string with the message you want will output it to the kernel logs you can view with dmesg. An example would be "pr_info("kgsl: clock set at 245mhz\n");"

    EDIT 3: I now know the values for all the GPU related clocks.
    Code: 
    <6>[   70.681793] kgsl: grp_clock= 256000000
<6>[   70.682464] kgsl: imem_clock= 256000000
<6>[   70.683441] kgsl: ebi1_clock= 128000000

    If you want to get these values yourself, the following code in the kgsl_clk_enable method will output them to the kernel log:

    Code: 
    	int clkg = clk_get_rate(kgsl_driver.grp_clk);
	int clki = clk_get_rate(kgsl_driver.imem_clk);
	int clke = clk_get_rate(kgsl_driver.ebi1_clk);

	// this will get the clock rate & print it in the kernel log
	pr_info("kgsl: grp_clock = %d", clkg);
	pr_info("kgsl: imem_clock = %d", clki);
	pr_info("kgsl: ebi1_clock = %d", clke);

    Just add that into the function I mentioned and it will output it to the kernel log, quite often in fact, so I wouldn't leave it in there except to see the values ;)


    EDIT 4: 7-2-2010
    Qualcomm has now released a new driver. It looks a lot better for our purposes. I'm looking through it today but I have other stuff I need to do. I will look at it, but I can't promise I can devote much time to it until at least Sunday.

    EDIT 7-7-2010:
    I've collaborate with storm99999 over GTalk and things aren't looking good. Here's what it comes down to:
    • If we try and lock it with any of the clk_set_rate methods, there is no effect. Not matter how we change it, it just stays at the original value. This either means it's set in the radio (impossible for us to change) or that it's set one time on boot and never changes, but we just don't know where it's actually set (more likely, but I'm not sure either way)
    • If we try and change it with msm_proc_comm, which is a direct interface to the hardware, it causes the kernel not to boot at all. This is really really strange. We can monitor the clock with pr_info as before, and if we read the data1 argument, it prints to the kernel fine, but if we try and read the data2 arg passed to msm_proc_comm, it also freezes on boot.

    We seem to be out of ideas here. We're open to any reasonable suggestions, so if you have any, PLEASE let us know in this thread or PM one of us. Or you can email me at geniusdog254@gmail.com
    View
    4
    tommypacker
    tommypacker
    Valantur said:
    Promising. It'd be awesome to have a flashable zip at our disposal to test it out.:fingers-crossed:
    Click to expand...
    Click to collapse

    I'll try to make one once i get my Nexus One out of a vegetable state

    Sent from my Nexus 4 using Tapatalk
    View
    4
    FeraVolt
    FeraVolt
    Just forgot to mention little thing.. Since we have now overclocked cpu..we have to correct max freq. value in acpuclock-8x50
    So search for this:
    Code: 
    case 0x00:
		max_acpu_khz = 998400;
    and change the value to 1190400.. Now you're done.


    Another QSD8K goodies will be here:
    http://xdaforums.com/showthread.php?p=49202903
    View
    3
    Dany0
    Dany0
    Saphrox, you idiot, you can't OC just the adreno GPU, THE END. Read the thread first...

    Sent from my HTC Desire using XDA
    View

New posts