Tuesday, December 13, 2016

The Discrete GPU and You

Chris Liscio:

The combination of a dGPU and lower-capacity battery means that the practical battery life of these machines gets cut in half (or worse) when the dGPU is active. I’m not sure that previous models had nearly as bad a “battery life delta” as these ones, but boy-howdy is it noticeable in practice on this system.


This whole problem can be very easy to solve. You just have to set NSSupportsAutomaticGraphicsSwitching key to YES in your application’s Info.plist. The trouble is that an OpenGL context is being created, which defaults to switching the dGPU on. Enabling this flag in the plist will very likely fix the problem on its own, as the frameworks should Do the Right Thing (more details below) if they need access to OpenGL.


To solve the bug I had, it turned out that I was making a call to -[NSOpenGLContext clearDrawable] in the dealloc method of my custom NSOpenGLView. My NSOpenGLContext was already destructed, and a whole new NSOpenGLPixelFormat was getting created and kicked the GPU on again. The call I should have used instead was -[NSOpenGLView clearGLContext] (though I don’t even know if that’s really required, to be honest.

Previously: macOS 10.12.2 Removes Battery Time Remaining Estimate, gfxCardStatus.

Update (2016-12-13): McCloud:

you can explicitly ask CoreGL not to turn on the discrete GPU

You need to create your context with kCGLPFASupportsAutomaticGraphicsSwitching - won’t trigger discrete transition.

3 Comments RSS · Twitter

Thanks for the link!

The CGL flag's description as above isn't totally accurate, though. As far as I can tell, that is equivalent to the plist entry I called out. Still, that's not enough to save you if you don't also specify that you can support offline renderers (i.e. the integrated GPU) in your pixel format.

Here's a thread I found regarding the CGL flag as above: http://lists.apple.com/archives/mac-opengl/2013/Apr/msg00008.html. Note that the CGL flag as above was called out as a solution for a command-line app to get the same behavior as the plist entry would buy them in an app bundle. It *doesn't* mention anything about CoreGL *not* turning on the discrete GPU. The message in the thread calls out the need for the "offline renderer" specification (via the TN link) as well as responding to virtual screen changes.

Unfortunately I've not yet investigated how Metal plays into this, but I'd bet good money that it better handles the multi-GPU case. Seeing how it was shipped after Apple already had a few flavors of multi-GPU configurations (the MBP and new Mac Pros).

Is this something that could be added to the Info.plist of an application you've already installed, which triggers the use of the dGPU? Or would that render the app unusable due to app signing?

@Jon The OS will launch apps with bad signatures. However, they will not be able to use entitlements. Also, some apps check the signature as a way of verifying that the app files aren’t damaged (or tampered with).

Leave a Comment