VirtualBox forces Mac laptops to use discrete GPU => Fixed in SVN

[cap10morgan]

VirtualBox forces Mac laptops to activate their discrete GPUs, thus shortening battery life. I could understand this if there were a 3D accelerated guest OS running, but it also happens when a headless guest is running or even when no guests are running.

VirtualBox should not force the discrete GPU on when not running 3D accelerated guests.

Others have confirmed this issue in the forums here:  https://forums.virtualbox.org/viewtopic.php?f=8&t=50574&p=234479&hilit=discrete#p234479

[ratbag]

This issue remains. To replicate:

1. Use a MacBook with multiple graphics card (confirmed on MacBook Pro Retina)
2. Install gfxCardStatus
3. Start a headless guest
4. gfxCardStatus reports that the discrete NVIDIA GeForce GT650M is in use
5. Watch battery life plummet
6. Attempting to switch to integrated graphics leads to error "You can't switch to integrated only while the following item is running: VBoxSVC"

Using Mac OS 10.8.2, gfxCardStatus v2.3, VitrtualBox 4.2.6 r82870, driven by Vagrant 1.0.6

[Bountin]

+1

[newtonick]

+1

[washley]

+1

[enrise]

+1

[ademuk]

+1

[FiloSottile]

+1

[vanten]

+111!1

[frank]

Yes, understood. But so far we don't have an idea why VirtualBox triggers using the discrete CPU. Investigations plus patches are welcome.

[dyname212]

+1

[mhanor]

If you search the web, you'll find that this issue isn't new. Maybe there's something to be learned from others.

 http://code.google.com/p/chromium/issues/detail?id=88788
 http://developer.apple.com/library/mac/#qa/qa1734/_index.html
 http://developer.apple.com/library/mac/#technotes/tn2229/_index.html

[chakatodd]

+1

[laird]

+1

[kevinwallace]

+1

[Lanchez]

+1

[dyname212]

+1 with the newest VB 4.2.14 version, please fix this the bateriies on macbook retina last for less than 2.3 hours

[phinze]

Just for fun I tried setting NSSupportsAutomaticGraphicsSwitching to true in VirtualBox's Info.plist as mentioned here:

 http://developer.apple.com/library/mac/#qa/qa1734/_index.html

I managed to generate two nearly identical VBoxSVC crash reports by trying to use vagrant after setting that bit.

 https://gist.github.com/phinze/da3b75a0219d6dec818e

Looks like a null pointer dereference somewhere in Appliance::Task. I'm way out of my league here, but conceptually it seems like we need to delay or avoid the creation of an OpenGL context in a headless environment. I'll see if I can get the chance to bomb around the VBoxSVC source this week and I'll post back here if I learn anything.

But anybody who actually knows what they're doing is more than welcome to chime in here. :)

[phinze]

Correction: The crashes I reported above were actually coming from #11895 - I had just upgraded to 4.2.14 before fiddling with this and the VBoxSVC crashes were happening on OVF imports.

So after getting on 4.2.16, the behavior when adding that Info.plist key is actually no change at all. The rest of my comments still apply, most especially the ones about me not knowing what I'm doing. ;)

[Diranged]

+1

This is a huge issue... it would be fantastic to get support for switching graphics drivers!

[frak]

+1

[drayne]

+1 !! I, and my battery will thank you

[dyname212]

Here is workaround that works for me. I get 5 hours with 3-4 instances running !!!!

I have the latest 4.2.16 VB installed. This works on both the lion and OS X 10.8.4 "mountain lion". Here is how can you get the virtual box work with integrated graphics. (YMMV)

1. Make sure that all VB instances are in "Powered OFF" mode.
2. Make sure that you don't have the "3d" or "2d" acceleration turned on under settings->Display
3. start the gfxcardstatus utility ( http://gfx.io)
4. switch the card to "I" integrated mode "Integrated Only" using gfxcardstatus
5. Start the VirtualBox
6. Start one of the instances the graphic mode should stay on "I" integrated mode

I didn't try to start VB from the terminal window. I tested this with winxp, win7 win764 win2k8 and others. Let me know if it worked for you!

[larstobi]

+1

[aktau]

+1, it's the single biggest battery drain on my MBP and limits my mobility quite a bit, as I always work with (headless) VMs for development. Since the upgrade to OSX Mavericks is free, perhaps it's a good idea to just focus on that OS in the beginning.

[larstobi]

+1

[larstobi]

If you're sure none of your VMs are using any graphics accelleration (2D/3D), you can add a line to the Info.plist yourself to avoid switching to the discrete GPU. Add this line within the <dict> tag in /Applications/VirtualBox/Contents/Info.plist:

<key>NSSupportsAutomaticGraphicsSwitching</key> <true/>

That stops my Macbook Pro from switching to the discrete GPU.

[larryweya]

I'm on a MBP early 2013 and recently upgraded to Mavericks and my headless VM's no longer switch to discrete graphics. Not sure about non-headless VMs though.

[klaus]

My guess is that this is caused by VBoxSVC running the 3D test (which is a separate executable), but I have no idea whatsoever why this permanently marks it as needing the "good" 3D.

Any OSX experts around who could give a hand? The number of "+1" posts can't speed up our work if we have no idea what's the root cause and how to change it.

[Armada651]

I'm not a complete Mac OS X expert, but I've done a lot of research on the subject of graphics switching. Any call to an OpenGL function will cause Mac OS X to switch to the discrete GPU until the application is closed.

In my experience it only happens when either starting a guest with 3D acceleration enabled (which expected behavior) or when I open the settings menu (that needs to be fixed). With the settings menu the discrete GPU stays in use until both the settings menu and the main window are closed. It doesn't matter whether a guest running simultaneously as long as it does not use 3D acceleration.

This lead me to believe this separate executable for the 3D test is only exited when the main window of VirtualBox closes.

EDIT: It will also persist on the guest if the settings menu is opened through its menus, meaning the guest has to be closed completely to switch back to the integrated GPU.

[frank]

First part of a fix is part of VBox 4.3.16.

[frank]

The 2nd part of the fix is part of the next maintenance release. Here is a test build.

[frank]

Could you confirm that this problem is finally fixed with VBox 4.3.18?

[Ringding]

Still happening for me when I open the machine settings dialog. OSX 10.9.4, MacBookPro6,2, VBox 4.3.18.

[Ringding]

Same with Yosemite.

[galitsyn]

Ringding, could you please attach VBox.log?

[Ringding]

Replying to galitsyn:

Ringding, could you please attach VBox.log?

Unfortunately, I don't think VirtualBox writes log information for opening the settings dialog.

[galitsyn]

Replying to Ringding:

Replying to galitsyn:

Ringding, could you please attach VBox.log?

Unfortunately, I don't think VirtualBox writes log information for opening the settings dialog.

Could you please run any VM on your Mac host and attach VBox.log which relates to it?

[Ringding]

Sure, but that does not switch the graphics card.

[galitsyn]

Replying to Ringding:

Sure, but that does not switch the graphics card.

Seems your VM has no 3D acceleration enabled. May I ask you to enable it and re-take log? Most likely graphics card switching is caused by 2D and/or 3D test execution which we run once settings dialog is opened. We enable offline rendering for both 2D and 3D tests if we correctly determine that Mac host has more than one GPU installed. Enabling 3D for VM should show if we do it correctly for your host. Btw, if you would build VBox from source -- 2D test will cause graphics switching because we patch Qt (and ship it) in order to enable offline rendering.

[Ringding]

Now with 3D acceleration

[Ringding]

Replying to galitsyn:

Replying to Ringding:

Sure, but that does not switch the graphics card.

Seems your VM has no 3D acceleration enabled. May I ask you to enable it and re-take log? Most likely graphics card switching is caused by 2D and/or 3D test execution which we run once settings dialog is opened. We enable offline rendering for both 2D and 3D tests if we correctly determine that Mac host has more than one GPU installed. Enabling 3D for VM should show if we do it correctly for your host. Btw, if you would build VBox from source -- 2D test will cause graphics switching because we patch Qt (and ship it) in order to enable offline rendering.

It's the official binary. Sure enough, with 3D acceleration enabled, display switching did indeed occur.

[galitsyn]

Ok, thanks for the logs. VBox.log shows that we enable offline rendering and graphics card switching should not occur. Let me think about it tomorrow morning. Btw, you don't have any ext monitor attached to you MBP, right?

[Ringding]

Replying to galitsyn:

Ok, thanks for the logs. VBox.log shows that we enable offline rendering and graphics card switching should not occur. Let me think about it tomorrow morning. Btw, you don't have any ext monitor attached to you MBP, right?

No. Integrated display, that’s all.

I have a version of Qt installed in /Library/Frameworks (4.8.5). Is it possible that there might be some interference coming from that?

[galitsyn]

I think this is not likely. May I ask you to attach sample report for VM process (sudo sample <VBox VM PID>)? It will show all dylibs used by the process.

[Ringding]

You were right. It linked against the bundled version.

[Ringding]

To clarify this: graphics switching is triggered by running a VM with 3D acceleration enabled (expected), but not when running one without 3D acceleration (also expected). It also happens when opening the machine settings dialog, either from the main manager window or from the running VM window itself (both not expected), the latter especially annoying because it will stay in discrete mode for as long as the VM continues to run.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.