gfxCardStatus
gfxCardStatus copied to clipboard
codykrieger
Fixed issue where 2010 MBPs switch to Discrete Only after apps quit
Hi Cody,
I'm a 2010 MBP user. I have been a fan of your app for a long time, using it to force the Integrated Only mode. The problem is that the mode will change to Discrete Only after certain apps which use Core Graphics close, such as Chrome or iOS Simulator.
The few lines of code I've added in fixes this problem:
- Created a static variable in GSMux to note which mode the user has selected
- In the displayConfigurationCallback section in GSGPU.m, if the user has selected Integrated Only but the discrete graphics is on, there will be a call to [GSMux setMode:] to change it back to Integrated Only.
- Do note that forceSwitch doesn't help in this case, since it resolves any discrepancy to the system mode, while my solution resolves it to the user's preference, which is how it should be.
Btw, I have also read that you have selected Dynamic Switching to default upon login so that the app runs smoothly. I think a better solution would be to first select Dynamic Switching to ensure the smoothness, then change it immediately afterwards to the user's last selected preference. What do you think?
Would this fix the issue for pre-mbp 2011 users to be able to use integrated graphics? This seems to be a big problem. More info here: https://discussions.apple.com/thread/4889454
Seems like this affects a lot of users, including me. I ended up downgrading to gfxcardstatus 2.1 in order to be able to force a certain mode on boot even though its buggy.
Thanks for this @highandfew!
In your experience using gfxCardStatus with this patch applied, has this caused any sort of negative side effects at any point? I'm wary of doing something like this just because I've seen some reeeeally wonky stuff happen when switching GPUs in rapid succession.
I'm not entirely opposed to pulling this in...I guess I just need more convincing that this won't blow up 2010 machines.
@swillis11 This would likely help work around the issue, but I'd really love to find a proper fix that doesn't require doing something like this.
@swillis11 The code I added doesn't force any mode on boot, so it will default to Dynamic Switching. But if you switch to Integrated Only, then it will stay that way until some CoreGraphics-utilizing app, like Chrome or more recently Reeder in 10.8.3, closes. Upon the closure of these apps, OS X automatically changes to Discrete Only for 2010 MBP users and I know of no way to prevent this. What I did was to add code so that once gfxCardStatus detects this, it immediately changes the Discrete Only back to Integrated Only. Hence for all purposes, you can say that your graphics remain in Integrated Only, once you set it as such in gfxCardStatus, until you next reboot your mac.
@codykrieger I have not done any extensive testing, but at least on my machine I can confirm it's very safe. Admittedly, it's quite a dirty fix, but displayConfigurationCallback seems like the only place where it's possible for gfxCardStatus to realize OS X's unwarranted switch to Discrete Only. I strongly urge you to pull this request for two reasons: i) it's a major convenience to MBP 2010 folks. ii) it will only affect the subset of users who use MBP 2010 and Integrated Only; in other words only the people who need the fix are at risk of "blowing up" their machines, and I'm inclined to think that they're very willing to take the gamble.
This problem affects me often, so I would be willing to test highandfew's modifications and report on whether I discover any unpleasant side effects. I have a Mid-2010 15" MacBook Pro.
Any chance you could give us a test build incorporating this patch, @codykrieger? Even just a build attached to this thread or something that we could try out. I swear I'll test it carefully and give feedback. :)
Could you post some build instructions, @codykrieger? I've checked out the project with submodules, but I still cannot get it to build. Is a special version of ReactiveCocoa or Xcode needed?
@henrik242 I haven't built the project in quite some time, so I'm not sure exactly what the problem might be. I'll see if I can give it a shot soon.
I am still interested in testing out the fix that @highandfew created. Unfortunately, I am in the same situation as @henrik242; I can't get the project to build even though I've also checked out ReactiveCocoa (I think I did it correctly). Any chance you could give us that test build incorporating @highandfew's patch, or some directions on how to get the build to work, @codykrieger?
If anyone is still interested, the version with my patch can be downloaded here: http://www.sendspace.com/file/xfzn4g
Excellent! I'll test this out and report back soon. Thanks, highandfew.
Jon
On 2013-07-31, at 2:51 AM, highandfew [email protected] wrote:
If anyone is still interested, the version with my patch can be downloaded here: http://www.sendspace.com/file/xfzn4g
— Reply to this email directly or view it on GitHub.
@highandfew's version seems to work perfectly. I put it through various tests to make sure that it did what it is supposed to do, and that it did not do anything it shouldn't do. It passed them all.
First, I tested it in situations that triggered the bug when using the standard build, and @highandfew's build handled them all excellently, every time.
Then I tried to see if I could find ways to make @highandfew's build perform the wrong behaviour. It always did the right thing.
- I tried to get the build to switch to the wrong configuration by selecting various modes while launching and quitting different combinations of applications that normally prompt the discrete GPU to activate. None of the permutations I tried resulted in bad behaviour.
- Most importantly, I also found that @highandfew's build never produced the situation where both GPU's would end up running at once. The existing check that refuses to switch to integrated only mode when an application is using the discrete GPU continues to function as it should with @highandfew's patch.
So, based on my testing, it seems that it would be a good idea to merge @highandfew's pull request into the gfxCardStatus master.
2010 MPB 17" NVIDIA geforce 330. Mavericks 10.9
If using "dynamic", things work as expected. i.e. open a power hungry program and gfxstatus changes to "discrete" close the program and it reverts back to "integrated"
However:
If one selects "integrated only" the status still changes to "discrete" on occasion. In this case, gfxcardstatus menu shows status changed to "discrete only" and doesn't revert to "integrated only" when the dependant program closes...
Is this expected behaviour?
@GraXXoR That's not the intended behavior, but it's currently expected, yeah...that's the issue that this whole thread is about. There's not a fantastic way to fix it.
That said, I'm leaning toward merging this pull request in, but I have about zero time to devote to it.
+1
I'm also using a MBP 2010 - there's one exception I think needs to be catered for:
If someone selects integrated only and then plugs in a display, will the system be caught in a loop of rapid graphics switching?
I've not tested this yet as I only found this thread today
Any updates on this issue? Can anyone else confirm the behaviour of highandfew's uploaded version?
The build that @highandfew posted above continues to work for me without problems to this very day. I have no idea if @codykrieger ever plans on pulling in the patch. If you want to see more updates on the issue, download highandfew's build and then post an update here describing how it worked for you.
Thank you for your reply. I ried @highandfew build, but it switches the GPU, which I don't like. I have a mid 2010 MBP with a faulty discrete GPU. I want to force the system in using the integrated only, which is why I still run version 2.1 of gfxCardStatus. I was hoping @highandfew build was a newer version of this, but instead, it switches to the discrete GPU if needed and switch back to the integrated GPU after that. I actually don't want to switch my GPU's anymore because of the faulty hardware.
Then your problem is not the same as the one that this is meant to fix. You want something to disable the discrete GPU, not something to work around a bug in the logic of the GPU switching code.
On 2014-05-24, at 2:06 AM, ElStuiterbal [email protected] wrote:
Thank you for your reply. I ried @highandfew build, but it switches the GPU, which I don't like. I have a mid 2010 MBP with a faulty discrete GPU. I want to force the system in using the integrated only, which is why I still run version 2.1 of gfxCardStatus. I was hoping @highandfew build was a newer version of this, but instead, it switches to the discrete GPU if needed and switch back to the integrated GPU after that. I actually don't want to switch my GPU's anymore because of the faulty hardware.
— Reply to this email directly or view it on GitHub.
@ElStuiterbal But wouldn't switching the GPU to integrated (not dynamic) achieve the same effect as disabling the discrete one? You'd always be using the integrated GPU. The discrete would be disabled.
@qnxor: No. highandfew’s version works by detecting when OS X switches to the discrete GPU and then immediately switching back to the integrated GPU if it determines that OS X was wrong to do so. The discrete GPU becomes active for a moment. ElStuiterbal’s problem is that he needs to avoid activating the discrete GPU ever at all. He is trying to deal with a hardware problem that only coincidentally is occurring on a 2010 MBP, whereas highandfew’s code is addressing a software problem specific to the 2010 MBP.
If I remember correctly, the previous builds were unaware that the discrete GPU was in fact running after closing a program that triggers the 330m whilst in 'integrated only' mode.
AFAIK, no build has ever been able to force the iGPU constantly.
On Sat, May 24, 2014 at 3:19 PM, Sesquipedalian [email protected]:
@qnxor: No. highandfew’s version works by detecting when OS X switches to the discrete GPU and then immediately switching back to the integrated GPU if it determines that OS X was wrong to do so. The discrete GPU becomes active for a moment. ElStuiterbal’s problem is that he needs to avoid activating the discrete GPU ever at all. He is trying to deal with a hardware problem that only coincidentally is occurring on a 2010 MBP, whereas highandfew’s code is addressing a software problem specific to the 2010 MBP.
— Reply to this email directly or view it on GitHubhttps://github.com/codykrieger/gfxCardStatus/pull/107#issuecomment-44088582 .
Interesting. I would have thought that if you first disable the dynamic switch in Mac OS X > Preferences > Energy Saver > Automatic graphics switching and then switch the GPU to integrated using gfxCardStatus, then it will remain switched (until next reboot) ... if not, what exactly makes it switch back to dynamic/discrete? Does going to sleep and waking up revert the state? That could be fixed with an event triggered script and my macoh.sh script (haven't tried).
@qnxor: That's what I want to know as well. I'm running gfxCardStatus as a login item now, followed by an Automator that runs bash macoh.sh -gpuswitch integrated. That keeps the status at "integrated only" for a long while.
I do have "Automatic graphics switching" disabled, and one of the problematic 2010 MBP's. But still, after a (long) while browsing on my computer, it switches to discrete.
I'm considering adding a cron job that detects discrete mode, but I haven't found an easy way to check for that status. I see that you use the log output from the gfxCardStatus startup, is there no other way?
@henrik242 Has the machine gone into sleep at any point? You could try to run the same command upon the wakeup event (haven't tried it): http://apple.stackexchange.com/questions/27036/possible-to-run-scripts-on-sleep-and-wake
Edit: do you run both gfxCardStatus as a GUI app, and also my macoh.sh script (which calls a different compiled binary)? If yes, try with just the macoh.sh script, the two binaries may clash otherwise.
Edit 2: Instead of a cron job that detects discrete mode, you could just cron the same macoh.sh command line that forces integrated mode (it's harmless if the integrated is already set). Do get rid of the GUI binary though, just to make sure. Currently the log output of gfxCardStatus is not very helpful in detecting the current mode (I hassled with that and had to hack my way around it in the macoh.sh script). gfxCardStatus does not exit either. The other way is to actually get your hands dirty in Xcode and use the IOkit framework (or direct calls) to poll the hardware ...
@qnxor Nope. I am able to reliably reproduce it by starting Firefox or Safari, running a certain kind of flash content (such as http://www.gameflare.com/online-game/trackmania-flash/ ), and quitting the browser. gfxCardStatus will switch to discrete mode.
EDIT 1: I run it both as a GUI app and via macoh.sh, otherwise I have no way of noticing when it suddenly switches back to discrete mode. I use the same binaries in both instances, so that should be OK.
EDIT 2: macoh.h seems so switch to nvidia and back to intel 2-3 times when I run it. Are you sure that isn't harmful if I do it every 5 minutes? It would certainly be quite annoying to see that switching n/i menu icon all the time :)
@qnxor : Did you look at the sticky mode branch, by the way? It would have been neat to have gfxCardStatus try to actively stay away from the discrete mode... https://github.com/codykrieger/gfxCardStatus/issues/150#issuecomment-33881337
For what it's worth, toggling the checkbox in Energy Saver prefs and then using gfxCardStatus directly thereafter is pointless...the underlying configuration that determines whether that checkbox is checked or not is what gfxCardStatus fiddles with.
(gfxCardStatus' "Dynamic Switching" mode is just another name for OS X's built-in automatic graphics switching feature.)
On May 26, 2014, at 1:20 PM, henrik242 [email protected] wrote:
@qnxor : Did you look at the sticky mode branch, by the way? It would have been neat to have gfxCardStatus try to actively stay away from the discrete mode... #150 (comment)
— Reply to this email directly or view it on GitHub.