Overclock.net › Forums › AMD › AMD CPUs › Analysis of Kaveri's Downclocking CPU to 3.0GHz when iGPU is under full load
New Posts  All Forums:Forum Nav:

Analysis of Kaveri's Downclocking CPU to 3.0GHz when iGPU is under full load

post #1 of 38
Thread Starter 
Analysis of Kaveri's Downclocking CPU to 3.0GHz when iGPU is under full load

It has long been known that without using a BIOS fix or other software manipulation that due to power constraints the Kaveri APU chips will force their CPU to down clock to 3.0GHz power state whenever the iGPU is under full load. It has often been speculated what the exact impact of this is on gaming performance. That speculation has lead to a couple of commonly held beliefs based on anecdotal evidence. They are as follows...

#1: The bandwidth bottleneck on the GPU is so large that lower CPU clocks will show little to no performance difference even if they were able to go higher than 3.0GHz.

#2: The clock speeds reported in monitoring software are inaccurate and while they show CPU clocks being held at 3.0GHz, they often jump intermittently between higher states and 3.0GHz depending on the iGPU load. This will allow much of the performance loss one would expect during gaming at lower CPU clocks to be nominal.

My testing will deal primarily with the second Hypothesis. In theory, if that statement is true, then with all other things being relatively equal we should see real performance gains over two tests where the only difference is CPU clock. Being locked at 3.0GHz or being able to periodically able to go higher during the test (even if software doesn't pick it up) would be the deciding factor.

For example, a CPU locked at 3.0GHz in BIOS during a test would exhibit less performance than one that was locked at 3.7GHz in the BIOS, and down clocks to 3.0GHz sporadically during the graphics test due to iGPU loads being high. But because it still maintains higher clocks at times during the run, its scores should show that benefit in the end.

However, should the 3.0GHz downclock actually be persistent, and software is reporting properly measured downclocks of 3.0GHz during heavy iGPU loads accurately; (which contradicts speculation #2) then we should see near identical performance between a test with higher CPU clocks and one with a CPU locked at 3.0GHz in BIOS.

Additionally, if the 3.0GHz cap is indeed persistent (and you choose not to use a software or BIOS fix) then you may find the fastest performance on your rig by locking the CPU at 3.0GHz (with possibly an undervolt to lower temps allowing more headroom on iGPU clock), and pushing your iGPU clock as high as possible.

NOTE: This lower CPU clock outside of gaming will nominally reduce performance during non iGPU heavy loads, but it will not have an impact during any gaming or other iGPU heavy workloads should the throttling indeed be persistent.


My testing method for this, as well as my Hardware set up is as follows:

Using 3DMark do I will do 4 runs of their Skydiver Bench Test, with each run having different Clock speeds on the CPU/GPU as follows.

CPU 3.0 / iGPU 720
CPU 3.7 / iGPU 720

CPU 3.0 / iGPU 1029
CPU 3.7 / iGPU 1029

Looking only at the tests that maximize iGPU load, I will record the FPS scores for GFX test 1 and 2 and the Combined Test and compare them. The Overall score and Physics test will be left out due to the fact that they both include data that does not put the iGPU under full load. This allows the CPU to maintain higher clocks during those tests. We are not investigating whether the CPU can maintain higher clocks under light iGPU loads such as the physics test or your OS home screen. We know it can. We only want to test it when the iGPU is under full load like it would be in any video game with demanding graphics. This type of heavy iGPU load only happens in GFX test 1, 2, and the combined test.

My Hardware list and setting is as follows:

Kaveri 7850K Variable clocks on CPU and iGPU as listed above
8GB Gskill Trident X @ 2133MHz C9.10.10.28.2T
MSI A88XM Gaming NB @1800

Final commentary...

If the tests shows significant performance gains with higher CPU clocks we can support speculation point #2 citing our test a evidence. If it does not, then we as a community should do further investigation into the matter and consider rejecting it.

The Results: proof.gif
Warning: Spoiler! (Click to show)



I will let the community decide for themselves what this means. I have done my part and will not have access to this rig for a long time after today as it goes home with my son today. Hope this was helpful. thumb.gif
Edited by gapottberg - 8/5/16 at 4:39pm
post #2 of 38
You're testing the wrong things . . . you've eliminated the physics portion of the test, and you're using a GPU-limited scenario to test the impact of CPU speed. Of course you are not seeing any changes.

Test a game at low res that is CPU-bound.

Also, on point #2, "anecdotal" evidence adheres to your notion that the chip downclocks constantly. The only reason why anyone knows that the chip actually moves rapidly between states is that The Stilt informed us of this fact. If you think he's wrong, you can tell him so next time you see him.
post #3 of 38
Thread Starter 
You miss the point again. We know a CPU will maintain higher clocks during low res, low load, low iGPU testing. The CPU is allowed to maimtain its higher clocks for most if not all of the run.

The point of this test is to show whether or not when the iGPU is topped out whether the software monitored drop of 3.0GHz is persistent as is displayed in most utilities...or whether the CPU is actually able to clock faster even though software says its not.

Hypothesis #2 was commonly touted as being true. That an iGPU at max load still was able to achive clocks higher than 3.0GHz even though software indicated otherwise.

My data suggests this is false.

The very fact that the physics score is higher only proves my point. It clearly shows under less than max load on thr iGPU, you DO net higher clocks which DO gain you performace.

If the same thing was indeed happening in the heavy iGPU load tests, we should see better results with a higher CPU clocks. I did not see that in my testing.

This thread as a whole is to open the discusion on the issue with Stilt or anyone esle who wants to contribute. Itnis by no means the emd all be all authority on the issue. Just data for those to consume and make their own tests and data and judgement calls.

In games where you have low res high cpu dependant tasks you are correct in saying keeping higher CPU clocks will net you better results. I never dispute that. That is what the data suggests is true.

My claim is and has always been that in any gaming situation where your iGPU finds itself under full load at or near 100% of the time...then a CPU overclock above 3.0GHz is wasted. It offers nothing or nearly nothing.

In those cases it makes more sense to OC the iGPU and leave the CPU at stock or even undervolt it at 3.0GHz to give your iGPU more OCing headroom.

My son plays games that almost exclusively top out his iGPU while in game. I discovered all this while trying to optimize his experience by collecting data for myself instead of just taking the forums advice at face value.

Hopefully that clears up my position...as you clearly are putting words in my mouth that contradicts what i actually said.
Edited by gapottberg - 8/6/16 at 10:47am
post #4 of 38
Would the OP regenerate the tests using PS Check program in order to elevate P3 state to normal working condition multiplier state?
The Machine
(14 items)
 
Nexus 7 2013
(11 items)
 
 
CPUMotherboardGraphicsRAM
A10 6800K Asus F2A85-V MSI 6870 Hawx, VTX3D 5770, AMD HD6950(RIP), Sap... G.skill Ripjaws PC12800 6-8-6-24 
Hard DriveOptical DriveOSMonitor
Seagate 7200.5 1TB NEC 3540 Dvd-Rom Windows 7 x32 Ultimate Samsung P2350 23" 1080p 
PowerCaseMouseAudio
Seasonic s12-600w CoolerMaster Centurion 5 Logitech G600 Auzen X-Fi Raider 
CPUMotherboardGraphicsRAM
Quad Krait 300 at 1.5Ghz Qualcomm APQ8064-1AA SOC Adreno 320 at 400mhz 2GB DDR3L-1600 
Hard DriveOSMonitorKeyboard
32GB Internal NAND Android 5.0 7" 1920X1200 103% sRGB & 572 cd/m2 LTPS IPS Microsoft Wedge Mobile Keyboard 
PowerAudio
3950mAh/15.01mAh Battery Stereo Speakers 
  hide details  
Reply
The Machine
(14 items)
 
Nexus 7 2013
(11 items)
 
 
CPUMotherboardGraphicsRAM
A10 6800K Asus F2A85-V MSI 6870 Hawx, VTX3D 5770, AMD HD6950(RIP), Sap... G.skill Ripjaws PC12800 6-8-6-24 
Hard DriveOptical DriveOSMonitor
Seagate 7200.5 1TB NEC 3540 Dvd-Rom Windows 7 x32 Ultimate Samsung P2350 23" 1080p 
PowerCaseMouseAudio
Seasonic s12-600w CoolerMaster Centurion 5 Logitech G600 Auzen X-Fi Raider 
CPUMotherboardGraphicsRAM
Quad Krait 300 at 1.5Ghz Qualcomm APQ8064-1AA SOC Adreno 320 at 400mhz 2GB DDR3L-1600 
Hard DriveOSMonitorKeyboard
32GB Internal NAND Android 5.0 7" 1920X1200 103% sRGB & 572 cd/m2 LTPS IPS Microsoft Wedge Mobile Keyboard 
PowerAudio
3950mAh/15.01mAh Battery Stereo Speakers 
  hide details  
Reply
post #5 of 38
Thread Starter 
I would, but i cannot since i no loger have the tower in question in my possesion as stated at the end of the 1st post. I have contributed as much as i can on the topic. It is up to you guys to collect your own data and maybe take my testing a step further in order to find what optimizations are best your your situation. This info was the best i could gather in the time i had.

Good luck.
post #6 of 38
Quote:
Originally Posted by mtcn77 View Post

Would the OP regenerate the tests using PS Check program in order to elevate P3 state to normal working condition multiplier state?

I think thats a great idea. Im currently doing a stupid build using kaveri. It wont be done for a while and its totally in pieces. However, if its together and no one else has re-run these tests then I will gladly do it, post results, and take requests for changing any and all variables.
post #7 of 38
there is a fix from The Stilt already wink.gif
post #8 of 38
Does it cover all motherboards, though?
The Machine
(14 items)
 
Nexus 7 2013
(11 items)
 
 
CPUMotherboardGraphicsRAM
A10 6800K Asus F2A85-V MSI 6870 Hawx, VTX3D 5770, AMD HD6950(RIP), Sap... G.skill Ripjaws PC12800 6-8-6-24 
Hard DriveOptical DriveOSMonitor
Seagate 7200.5 1TB NEC 3540 Dvd-Rom Windows 7 x32 Ultimate Samsung P2350 23" 1080p 
PowerCaseMouseAudio
Seasonic s12-600w CoolerMaster Centurion 5 Logitech G600 Auzen X-Fi Raider 
CPUMotherboardGraphicsRAM
Quad Krait 300 at 1.5Ghz Qualcomm APQ8064-1AA SOC Adreno 320 at 400mhz 2GB DDR3L-1600 
Hard DriveOSMonitorKeyboard
32GB Internal NAND Android 5.0 7" 1920X1200 103% sRGB & 572 cd/m2 LTPS IPS Microsoft Wedge Mobile Keyboard 
PowerAudio
3950mAh/15.01mAh Battery Stereo Speakers 
  hide details  
Reply
The Machine
(14 items)
 
Nexus 7 2013
(11 items)
 
 
CPUMotherboardGraphicsRAM
A10 6800K Asus F2A85-V MSI 6870 Hawx, VTX3D 5770, AMD HD6950(RIP), Sap... G.skill Ripjaws PC12800 6-8-6-24 
Hard DriveOptical DriveOSMonitor
Seagate 7200.5 1TB NEC 3540 Dvd-Rom Windows 7 x32 Ultimate Samsung P2350 23" 1080p 
PowerCaseMouseAudio
Seasonic s12-600w CoolerMaster Centurion 5 Logitech G600 Auzen X-Fi Raider 
CPUMotherboardGraphicsRAM
Quad Krait 300 at 1.5Ghz Qualcomm APQ8064-1AA SOC Adreno 320 at 400mhz 2GB DDR3L-1600 
Hard DriveOSMonitorKeyboard
32GB Internal NAND Android 5.0 7" 1920X1200 103% sRGB & 572 cd/m2 LTPS IPS Microsoft Wedge Mobile Keyboard 
PowerAudio
3950mAh/15.01mAh Battery Stereo Speakers 
  hide details  
Reply
post #9 of 38
Quote:
Originally Posted by gapottberg View Post

You miss the point again. We know a CPU will maintain higher clocks during low res, low load, low iGPU testing. The CPU is allowed to maimtain its higher clocks for most if not all of the run.

What are you talking about? If you put a CPU/GPU combo in a GPU-bound situation, changing CPU clockspeed won't affect performance unless its severe throttling we're talking about, which 3.7->3.0 GHz really isn't. The whole point of going with a CPU-bound scenario is to show noticeable changes in performance per 100 MHz of clockspeed gained/lost, not to take load off the iGPU. I can assure you that some old Source engine game like TF2 will trigger GeAPM throttling, even at low resolutions.
Quote:
Hypothesis #2 was commonly touted as being true. That an iGPU at max load still was able to achive clocks higher than 3.0GHz even though software indicated otherwise.

. . . because we're all parroting The Stilt who is generally correct about these things.
Quote:
My data suggests this is false.

It's also inconclusive.
Quote:
The very fact that the physics score is higher only proves my point. It clearly shows under less than max load on thr iGPU, you DO net higher clocks which DO gain you performace.

You do realize the physics test still pushes the GPU about as hard as the standard test, right? Hell go run the combined test on FireStrike if you're that concerned about GPU load dropping during the physics test.
Quote:
If the same thing was indeed happening in the heavy iGPU load tests, we should see better results with a higher CPU clocks. I did not see that in my testing.

No you wouldn't. Higher CPU speeds can't push the iGPU to perform better. Once it's at its limits, it's at its limits, hence the reason for not using GPU-bound tests when comparing CPUs, different CPU clockspeeds, or even different RAM speed/timing configurations.
Quote:
In those cases it makes more sense to OC the iGPU and leave the CPU at stock or even undervolt it at 3.0GHz to give your iGPU more OCing headroom.

While that is somewhat true, it's for reasons that are different than those which you articulate. It's because the iGPU is holding things back.
Quote:
...as you clearly are putting words in my mouth that contradicts what i actually said.

. . . uh-huh.
post #10 of 38
Thread Starter 
Quote:
changing CPU clockspeed won't affect performance unless its severe throttling we're talking about, which 3.7->3.0 GHz really isn't.
So you're telling me a 23% drop in CPU clock speed isn't significant? Gotcha. rolleyessmileyanim.gif

Quote:
You do realize the physics test still pushes the GPU about as hard as the standard test, right?

This is blatantly false. The Physics test puts bare minimum load on the GPU and stresses primarily the CPU. You can actually measure your CPU clocks going above the 3.0GHz cap in software when running it on an APU. Also, most GPU's will drop to lower clock states if they have multiple P states and the %GPU load in monitoring will also fall way below the 100% mark where it is usually at 100% during the whole run for the other tests i used.

[EDIT] Since i had a TS test up i had just run on my Serenity build, i went ahead and took this pic. It clearly shows the GPU %load being significantly less in the Physics portion of the test which is the exact same pattern you will see on all 3DMark physics tests.

Warning: Spoiler! (Click to show)


Quote:
Hell go run the combined test on FireStrike if you're that concerned about GPU load dropping during the physics test.

I did run a combined test, in Skydiver. Using Fire strike would make measurable differences between samples even smaller than they are now and could potentially be used to skew the results further in my favor even if they were false, which is why i used Skydiver in the first place. I wanted results with measurable degrees of difference on settings that more closely related to what the hardware was capable of.

Quote:
It's also inconclusive.


Since i never claimed it was definitive proof of anything, why even point this out? You are just saying what i already said, or you are trying to make it seem like i said something i didn't. I said it suggested Hypothesis #2 was false and more investigation was needed. I also clarified my position with the following statement later on...

"This thread as a whole is to open the discussion on the issue with Stilt or anyone else who wants to contribute. It is by no means the end all be all authority on the issue. Just data for those to consume and make their own tests and data and judgement calls."


So "Uh HUH", stop trying to put words in my mouth. It makes you look like a fool using a straw man tactic and is unwelcome in the contribution to the topic.
Edited by gapottberg - 8/7/16 at 2:18pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: AMD CPUs
  • Analysis of Kaveri's Downclocking CPU to 3.0GHz when iGPU is under full load
Overclock.net › Forums › AMD › AMD CPUs › Analysis of Kaveri's Downclocking CPU to 3.0GHz when iGPU is under full load