The dGPU: Killing Battery Life

The 15 and 17-inch MacBook Pros have a discrete GPU that only turns on if you fire up an application that really needs it—at least that's how it is supposed to work. In practice, the discrete GPU takes over control if your application uses any one of a number of frameworks—and some of the time, the dGPU simply isn't necessary.

Case in point, launching Chrome won't trigger a dGPU switch but the moment it encounters Flash the discrete GPU will take over. The bad news is that even if you close all Chrome windows, the dGPU won't power down until you quit chrome entirely. The same is true for Photoshop. Launch the application and you're still on the iGPU. Actually open up an image and the dGPU takes over. Even if you close all open images and just leave the Photoshop application open, the dGPU won't relinquish control. FaceTime and anything using the integrated camera also require the dGPU, despite it being totally unnecessary.

If you connect any external display to the 15 or 17-inch MacBook Pro that also forces the dGPU on, at which point both the integrated panel and external display are driven by the dGPU. There is no funny frame buffer copying going on, both the integrated and discrete GPUs have their own connection to the display.

Apple also fails to provide a way of turning off the dGPU by default—the best you can do is shut off the iGPU and just use the dGPU entirely. Thankfully Cody Krieger's gfxCardStatus tool gives us exactly what OS X does not. Version 2.0.1 adds support for the 2011 MacBook Pros.

I'm going on and on about the dGPU because it's state can seriously impact battery life. The numbers below should help put that in perspective for you:

Impact of Discrete GPU on Battery Life
15-inch 2011 MacBook Pro Light Web Browsing Flash Web Browsing
Integrated GPU (Intel HD 3000) 8.85 hours 7.03 hours
Discrete GPU (AMD Radeon HD 6750M) 5.67 hours 2.97 hours

Even just browsing the web, the dGPU being on drops battery life by 35—60%. Under full CPU load I suspect the percentage difference would be smaller, but still significant. The worst part of this all is that without gfxCardStatus you can negatively impact battery life by doing something completely innocent like accidentally leaving an application open. Given how much OS X is tailored to simply closing windows when you're done with them and not quitting applications, an overly aggressive dGPU can really be an issue.

Thankfully we do have gfxCardStatus but there's honestly no reason Apple shouldn't include this functionality with OS X from the start.

The GPU Comparison Display Quality
POST A COMMENT

198 Comments

View All Comments

  • Anand Lal Shimpi - Friday, March 11, 2011 - link

    Thank you for reading them, comments like this really do make it all worthwhile :)

    You wouldn't believe how much time was spent making sure Apple wasn't doing something funny with the max turbo frequencies. At the end of the day it was a non-issue, but we had to be sure.

    Take care,
    Anand
    Reply
  • Ryan Smith - Friday, March 11, 2011 - link

    Just to add some technical background to this, it's actually quite complex to get a CPU speed reading on modern CPUs. Mac OS X's Sysctl reports the base speed of the processor, regardless whether Turbo Mode is active or not. So on the 15" low-end QC model you will always see 2.3GHz.

    To actually read the instantaneous speed of any given core, you need to peek at the CPU itself and count the cycles - Intel actually has a handy document detailing an algorithm to do this(1). The issue with that is that it requires peeking at the Model-Specific Registers (MSRs), which require Ring 0 access; or in other words you need a broker at the driver level to do it.

    Linux already does this (/proc/cpu/0/msr), and on Windows it's fairly trivial to load a driver alongside an Admin-level application to do this(CPU-Z, etc). Under Mac OS X this requires installing an Extension (at least as far as I know) which gets messy. If you don't go through this process you'll never be able to read the core speeds accurately, which is why there's virtually no Mac software capable of this.

    Fortunately MSR Tools exists, and it has a 32bit extension to allow it to peek at the MSRs. The right answer of course is always the last answer you try, so this was only after trying several other ways of calculating the CPU speed and a couple different OS-agnostic benchmarks to try to rule out OS differences.

    1) http://download.intel.com/design/processor/applnot...
    Reply
  • tno - Friday, March 11, 2011 - link

    +1

    I've been planning to plunge into Mac ownership for sometime, especially with grad school looming I really want something that's more comfortable to work on than my netbook but still fairly portable. This review really helped me gauge whether it was worth putting in the extra cost for a 2011 13" MBP or settle for a discounted 2010.

    So am I all set? Hardly! Now I need to see what the 2011 13" MBA has to offer! I'm praying that cost stays roughly the same and a move to a ULV SNB leads to 12+ hour battery life and a similarly huge leap in performance as the move lead to in the MBP. I am a sucker for lightweight form factors.

    This article is also the first one to make me ever consider the 15" MBP. I have been fairly opposed to the bulk but the performance is quite something. If I went that route then I would probably have a C2Q, water-cooled, ATI and SSD driven rig to put up on AT forums. Taking offers!
    Reply
  • tno - Wednesday, May 4, 2011 - link

    Rezzing a dead thread! I bought the 13" MBP! $999 at MicroCenter, too good to pass up! So . . . who wants my rig? Reply
  • JasperJanssen - Saturday, August 6, 2011 - link

    I, on the other hand, have gone the other way. My MBA13 is being put together in China now. Reply
  • ltcommanderdata - Thursday, March 10, 2011 - link

    A great review. I do have some additional questions though. First, given Apple was the instigator of OpenCL, it'd be great if you could run some OpenCL benchmarks. Are the Sandy Bridge MacBook Pro's disproportionately faster than the Arrandale MacBook Pro to indicate that OS X has CPU OpenCL drivers that can take advantage of AVX? Probably not, and this will hopefully come with Lion. Given nVidia's GPGPU push can the HD 6490 still keep up with the 330M GT in OpenCL? How does the HD6750 do?

    http://www.bit-tech.net/hardware/graphics/2011/01/...

    "'[Intel] will be releasing OpenCL graphics drivers to developers during the course of 2011. [Intel] continue to evaluate when and where OpenCL will intercept various products"

    And is there secret Sandy Bridge IGP OpenCL support? Bit-tech got a quote from Intel that Sandy Bridge IGP OpenCL support was inbound sometime this year and if anyone would be motivated to get it done it'd be Apple.

    And finally, does Apple now support hardware H.264 decoding on ATI or Intel GPUs? Previously, only a few nVidia GPUs were supported in Snow Leopard, such that the Arrandale MacBook Pro actually had to power up the 330M GT to decode H.264 wasting power compared to the perfectly fine Arrandale IGP if Apple just wrote the drivers. Do the new Sandy Bridge have the ATI GPUs doing H.264 decoding now, is the Intel IGP supported, or in the worst case is no H.264 hardware acceleration available now that nVidia GPUs are gone? Perhaps lack of hardware H.264 decoding is what makes the FaceTime HD CPU usage so high? QuickSync is only accelerating the encoding phase?
    Reply
  • Anand Lal Shimpi - Friday, March 11, 2011 - link

    Some answers:

    1a) I don't know of any good GPU based OpenCL tests under OS X at this point. I'm not even sure if Apple's Intel HD 3000 driver supports OpenCL.

    1b) Intel mentioned SNB's GPU technically supports OpenCL however there are no plans to release a public driver at this point.

    2) Hardware H.264 decoding is enabled on the 2011s and it is used while FaceTiming, at least according to Apple.

    Take care,
    Anand
    Reply
  • ltcommanderdata - Friday, March 11, 2011 - link

    Thanks for the reply.

    http://www.macupdate.com/app/mac/33632/smallluxgpu

    In regards to OpenCL testing, most people in OS X seem to use SmallLuxGPU which is an OpenCL raytracing benchmark. I don't have much experience with it, but it might be worth a try.

    In regards to hardware H.264 decode, do you know if the IGP is doing it or does the discrete GPU still have to be powered up as in the 2010 Arrandale MacBook Pros?

    Thanks
    Reply
  • Anand Lal Shimpi - Friday, March 11, 2011 - link

    It's my understanding that the IGP can do the decoding, although note that while FaceTime is running the dGPU is enabled by default.

    Good call on SLG, I had forgotten about that :)

    Take care,
    Anand
    Reply
  • secretmanofagent - Thursday, March 10, 2011 - link

    Hello authors,
    On one of the pages, you mentioned this:
    "This isn't Mac specific advice, but if you've got a modern Mac notebook I'd highly recommend upgrading to an SSD before you even consider the new MacBook Pro. I've said this countless times in the past but an SSD is the single best upgrade you can do to your computer."

    Is there an article where you recommend the best update for my model? Should I even bother with the drive? I realize the X3100 is going to still hamper any sort of graphical performance, but wondering if it's worth the effort.

    Out of curiosity as well, would a Time Machine restore be possible if you update the drive?
    Reply

Log in

Don't have an account? Sign up now