Jump to content

E6510: NVS 3100M throttling


Dr. Monkey
 Share

Recommended Posts

Hi, I wanted to see if anyone actually got their GPU to a speed state other than 405Mz.  I saw that a fakesmc with the necessary patch was posted in this thread, but haven't seen any confirmation that it actually worked.  Its something I fought for a long time and had given up, but if someone has actually solved this, I would love to know so I can try again.
 
Attaching a zip with my IOREG dump as well as my entire EFI/CLOVER folder

IOREG_DSDT_EFI.tar.gz

Link to comment
Share on other sites

Thanks for splitting off to a new topic. I have been through all of those guides and spent a couple weeks working on it back in the winter without success. I even got as far as seeing the messages about switch in states in the log, but HW monitor showed no change in frequency. I was trying to figure out if that is expected behavior or if I am missing something.

Thanks in Advance
Edit: also wanted to mention that I did try the fakeSMC you created for the original thread, but it did not make any difference

Link to comment
Share on other sites

  • Administrators

The tuned FakeSMC is essentially targetting native CPU SpeedStep. For GPU throttling, you have to look at the AGPM tuning and experiment as mentioned in the guide. I've no straight answer for any given GPU model...

 

The guide mentions how to log GPU throttling behaviour, so use that to verify actual GPU state changes and then experiment with threshold levels.

Link to comment
Share on other sites

I guess I am a bit confused then.  In the original post, you wrote

"I'll also inject an AGPM section to your FakeSMC to target your NVS 3100M GPU (ven/dev id 10de/0a6c). I'll reuse the same parameters as I did for nVidia NVS 135M of the D630/D830 series or NVS 160M of E6400/6500 series. It may turn out not fully optimum and may require further tuning but will nevertheless hopefully provide you with proper GPU throttling"

 

I interpreted that to mean that you were injecting a AGPM patch using FakeSMC. Is that incorrect?  if so, my apologies.

Link to comment
Share on other sites

  • Administrators

That's exactly it: instead of patching the AGPM kext in /S/L/E, something one would require re-doing after each OS X update, FakeSMC can instead be used to inject the same patch. FakeSMC never gets replaced or overwritten at OS X updates, so the patch remains effective throughout.

 

Make sure you start from your original AGPM Info.plist code, do not copy the code I posted to illustrate my thread because it may not match the vanilla AGPM version.

Link to comment
Share on other sites

OK thanks for confirmation.  I enabled logging for AGPM and I get the following in /var/log/system.log

system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(0, 0): fHwPstate = 0 fFB = 0xffffff802df38800
system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(): state = 0. Calling fFB->setAggressiveness()...
system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: GPU = VID G-state set to 0 from 0, ControlID = 18. SW occupancy updated.
system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(1, 0): fHwPstate = 0 fFB = 0xffffff802df38800
system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(): state = 1. Calling fFB->setAggressiveness()...
system.log:Sep  9 12:46:08 MacBookFaux kernel[0]: AGPM: GPU = VID G-state set to 1 from 0, ControlID = 18. SW occupancy updated.
system.log:Sep  9 12:46:10 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(2, 0): fHwPstate = 1 fFB = 0xffffff802df38800
system.log:Sep  9 12:46:10 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(): state = 2. Calling fFB->setAggressiveness()...
system.log:Sep  9 12:46:10 MacBookFaux kernel[0]: AGPM: GPU = VID G-state set to 2 from 1, ControlID = 18. SW occupancy updated.
system.log:Sep  9 12:46:12 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(3, 0): fHwPstate = 2 fFB = 0xffffff802df38800
system.log:Sep  9 12:46:12 MacBookFaux kernel[0]: AGPM: updateGPUHwPstate(): state = 3. Calling fFB->setAggressiveness()...
system.log:Sep  9 12:46:12 MacBookFaux kernel[0]: AGPM: GPU = VID G-state set to 3 from 2, ControlID = 18. SW occupancy updated.

However I do not see any change in frequency in HWMonitor.  Could it just be a matter of the sampling rate of HWMonitor not picking up the fluctuations?

Link to comment
Share on other sites

  • Administrators

Ok, so you have throttling between 4 states (0, 1, 2, 3) -which is good news- but I guess the current threshold values are not adequate. You need to play with those until you find settings that are good in terms of performance on screen.

 

For instance, you'll see in my guide that I adjusted the default MBP5,1 threshold values from:

<key>Threshold_High</key>
<array>
<integer>57</integer>
<integer>65</integer>
<integer>82</integer>
<integer>100</integer>
</array>
<key>Threshold_Low</key>
<array>
<integer>0</integer>
<integer>68</integer>
<integer>75</integer>
<integer>95</integer>
</array>

to:

<key>Threshold_High</key>
<array>
<integer>57</integer>
<integer>65</integer>
<integer>74</integer>
<integer>100</integer>
</array>
<key>Threshold_Low</key>
<array>
<integer>0</integer>
<integer>40</integer>
<integer>60</integer>
<integer>75</integer>
</array>

That was done over a period of time, setting values and testing/evaluating graphics performance of my NVS 135M until I felt satisfied, the aim being mostly of minimising the delays for throttling GPU core/RAM speeds up and down according to graphics demand/load.

 

As I said, I've no direct and/or straight method to set those threshold values according to GPU model. It's purely a manual "set and test" method. In your case, you should start from the MBP6,1/6,2 default settings of one or the other nVidia entries (vendor 10de). You may also experiment with control-id value, i.e. 17 or 18. I would not refer to the threshold of the Intel 1st gen HD iGPU (8086:0046).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...