MacBook Pro: How to disable discrete GPU permanently from EFI?

Question

I'd like to disable the NVidia GTX 750M GPU on my MacBook Pro 15" (Retina, Mid 2014, Mac OS X 10.10 Yosemite). I know I can use GfxCardStatus but I read I could have a more permanent solution by changing some EFI flag.

My question is:

• How can I disable the discrete GPU from EFI?

  I assume this is persistent across multiple reboots. I'd also want to know how to undo it if needed.

Update:

The question is basically whether the command mentioned in GfxCardStatus github issue comment here is correct or not, and how to undo it if it doesn't work.

.

An answer to this alone is a correct answer, but it'll be awesome if you can also tell me:

• If you force integrated graphics in GfxCardStatus, Mac OS X (up to Yosemite at least) doesn't allow you to use multiple monitors (even though the built in Iris Pro can do it).

  If I disable the discrete GPU from EFI, will macOS think that the integrated GPU is the one installed and will it let me use multiple monitors with it?

• I heard that the same EFI setting is responsible for not even showing the integrated GPU to other operating systems than macOS and you have to trick it somehow to think it's macOS.

  Is that true? And if yes, how to do that?

Answer 1

You can permanently disable discrete graphics card following next steps:

UPDATE! Try to edit NVRAM variable from Single-User mode

The procedure described in the steps 1-3 worked for me until macOS Sierra, but with the upgrade to High Sierra, I started getting a pinkish/reddish screen and I was unable to enter Recovery mode to repeat step 3 as I had to do in previous upgrades. Searching in internet, I stepped into this GitHub issue explaining you may be able to replace steps 1 and 2 with the following command, that you can execute in Single-User mode (boot pressing cmd+s):

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

1. Prepare a Bootable USB pendrive with a non GUI Linux

1.1 Download ArchLinux ISO

• You need a working computer for that and a spare CD/DVD/USB drive.
• Download the latest Arch Linux ISO image.
• Then you could either simply burn this ISO to CD/DVD (which later could be either inserted to MBP's SuperDrive or External DVD Drive connected to MBP by two USB cables) or create a bootable USB.

1.2 Creating the bootable USB with the .iso

• First, you need to identify the USB device.

• Open /Applications/Utilities/Terminal in MacOS and list all storage devices:

  diskutil list

  Your USB device will appear as something like /dev/disk2 (external, physical). Verify that this is the device you want to erase by checking its name and size and then use its identifier for the commands below instead of /dev/diskX.

• A USB device is normally auto-mounted in macOS, and you have to unmount (not eject) it before block-writing to it with dd:

  diskutil unmountDisk /dev/diskX

• Now copy the ISO image file to the device. The dd command is similar to its Linux counterpart, but notice the 'r' before 'disk' for raw mode which makes the transfer much faster:

  sudo dd if=path/to/arch.iso of=/dev/rdiskX bs=1m

  After completion, macOS may complain that "The disk you inserted was not readable by this computer". Select 'Eject'. The USB device will be bootable.

2. Use Linux to change EFI vars

2.1 Boot to it

• Insert this CD/DVD/USB to Macbook Pro, hold Option key (alt) while booting.
• Choose "EFI boot" (that is your bootable installation media).
• When the menu shows, press "e" key to edit the GRUB options of the Arch Linux archiso x86_64 UEFI CD menu entry while it is selected at the main screen, add nomodeset to the end of this line and press Enter.
• If everything is done correctly, you will find yourself at the Linux console! (It takes some time so be patient and wait for the prompt)

2.2 Clear existing EFI vars

Looks like efivarfs filesystem is mounted by default! So you can already cd /sys/firmware/efi/efivars and ls to explore this directory and see if there is a gpu-power-prefs-... variable (where ... is UUID of this variable).

• If there is such a variable, it's better to remove it with rm.

  rm gpu-power-prefs-…

• If you are getting the "operation not permitted" message while attempting to rm, it means that efivarfs has been mounted as read-only and you need to remount it with read-write permissions and try again:

  cd /
umount /sys/firmware/efi/efivars/
mount -t efivarfs rw /sys/firmware/efi/efivars/
cd /sys/firmware/efi/efivars/
rm gpu-power-prefs-…
  

• If this also fails (you still can’t erase the file), use chattr command to disable file immutability and then erase the file:

  chattr -i "gpu-power-prefs-…”
rm gpu-power-prefs-…
  

2.3 Create a new gpu-power-prefs-… file

printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9

2.4 Add immutability to the gpu-power-prefs-… file

This chattr command is supposed to lock a file to make it accessible only by "superuser" - and so that, while booting, your EFI will have no chance to screw up your gpu-power-prefs-... variable under any circumstances

chattr +i "/sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9"

2.5 Unmount efivars and reboot

Change to the root directory to unmount efivars:

cd /
umount /sys/firmware/efi/efivars/

Guarantees that your EFI variables are flushed to efivarfs filesystem. Please unmount it safely before rebooting.

reboot

3 Remove AMD / NVIDIA kexts

Note: You might need to do this every time you update your OS, since it normally regenerates these kexts. You may want to favourite this answer for reference so it is accessible from another device when you need it.

After disabling the dGPU using Arch, normal boot would hang halfway but safe boot will work.

3.1 Move AMD / NVIDIA kext files to a backup directory

Remove all the AMD (or NVIDIA, depending on your card) kext files in the Terminal in Recovery Console. Trying to remove them in Single User just gives sandbox errors, so don’t do it in Single User Mode! (the one that you boot with cmd+s).

• If you have FileVault, unlock it first.
• Boot into Recovery (cmd+r) directly. If it fails, then repeat step 2 and retry (dGPU could get active again after booting into the os with AMD / NVIDIA kexts).

• Start Terminal (This commands are for AMD. If you have NVIDIA, change accordingly)

  diskutil cs list (find Logical Volume UUID: last item)
  diskutil coreStorage unlockVolume UUID (UUID: from previous command)
  cd /Volumes/Macintosh\ HD
mkdir AMD_Kexts
mv System/Library/Extensions/AMD*.* AMD_Kexts/
reboot
  

I found the procedure in this link, where you can read the attribution of the different sections and a discussion thread on the topic.

I tried it myself on an early 2011 MacBook Pro with a faulty discrete graphics card, that was unable to boot even with the overheating trick, and ended up with a fully functional computer!

Answer 2

Your Dilemma

I'm in full sympathy with your wish "save on battery and reduce heat, without paying the noise cost" of using the discrete graphics card inside a MacBook Pro.

Warning

Before you do anything which will disable your display, please make sure you are able to log in to your MacBook Pro using SSH so that you can undo your handiwork. While screen sharing with all graphic cards disabled will probably work at some default resolution, I wouldn't bet my computer on it.

Answers

What will happen if I permanently disable the discrete nVidia graphics card from EFI? Will Mac OS think integrated GPU is the one installed and let me use multiple monitors with it?

You will lose any ability to use an external monitor (under any OS). The external graphics port(s) are wired to the discrete graphics chip.

My own MacBook Pro 2011 runs at a stable 60 degrees even under load with minimal fan noise when using the built-in Intel graphics and spikes to full fans (in the 4000 to 6000 RPM range) when under load with the discrete 6750. The problem is real. I too wanted to be able to only use the built-in graphics and drive an external monitor.

No way, no how.

Is it true that the same EFI doesn't even show the integrated GPU to other OSes than Mac OSes and you have to trick it somehow to think it's Mac OS?

Yes, it's true. The Intel GPU gets switched off by the MacBook Pro 11,3's EFI if you boot anything but Mac OS X. You have four choices if you want to use the integrated Intel chip under alternative OS:

1. rEFInd version 0.10.0 or above (recommended): http://www.rodsbooks.com/refind

Recent versions of rEFInd have the "apple_set_os" hack built-in. You can enable it by setting the spoof_osx_version option in your refind.conf.

2. apple_set_os.efi: https://github.com/0xbb/apple_set_os.efi

3. a patched GRUB: https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html https://wiki.archlinux.org/index.php/MacBookPro11,x#Getting_the_integrated_intel_card_to_work_on_11.2C3

4. a patched Kernel: https://www.marc.info/?l=grub-deavel&m=141586614924917&w=2

Be careful to plan ahead. If you don't prepare, you will face a powered-down integrated graphics card and a black screen. Of course you can always go back and boot Mac OS X and start again.

The simplest of the choices above would be number two - to replace the Apple EFI. Unfortunately, it's the one which could leave you unable to boot up at all at some future date. Apple does not like people to play with EFI and reserves the right to brick your device for doing so. If you had Apple Care and were still in the warranty period, you might find a shoulder somewhere to cry on. Might. When you change EFI, you also take security risks, i.e. you may make it easier to hack your machine. You need to be able to update to the latest EFI which would remove your patch.

Option one, rEFInd puts itself between boot and EFI, which leaves considerable scope for something to go wrong and for you to be left with a brick and a long hard trail back to a working computer. How serious are these issues? Many MacBook Pro owners have lost their hard drive to rEFInd:

Numerous rEFIt bug reports indicate disk corruption problems on disks over about 500 GiB....I strongly recommend that you not type sudo bless --info to check the status of your installation if you have such a disk, or even if you suspect you might have such a disk. (I've seen Advanced Format disks as small as 320 GB.)

Option three is relatively easy. Patching grub is a process with which any early Hackintosh owner is quite familiar. Patching Grub works and is easily undoable as the changes are not made at the firmware level. If you patch grub conservatively, the additional grub code is only enabled by holding option/alt on boot.

Conclusion

If you prefer using your computer to repairing it, Cody Krieger's gfxCardStatus in its out-of-the-box configuration looks more and more attractive. If you really want to force gfxCardStatus to run at start Mr. Krieger has participated in an illuminating conversation, which has led to switchGPU. switchGPU presets gfxCardStatus to either discrete or integrated graphics early enough that you can run on integrated graphics when your discrete GPU would otherwise overheat and crash. gfxCardStatus continues to operate normally (i.e. you can switch back to discrete GPU after boot using the gfxCardStatus menu item). There's no reason to install switchGPU unless you have serious hardware issues with your discrete GPU which mean you need to keep it turned off all the time.

Coda

On reflection, my own situation with the integrated AMD 6750 is bad enough (so hot and loud even after thermal repasting) that I will avail myself of Apple's extended warranty repair program for 2011 MacBook Pro with AMD graphics. Marco Arment was probably right to turn in his 2011 2.2 GHz MBP with 6750 for the 2.0 GHz version with 6490. While I considered doing the same thing at the time, I would have had to ship my MBP overseas to change it. Sadly the Retina MacBook Pros appear to continue to suffer the same heat and noise issues. My girlfriend's 2013 MacBook Pro with only integrated graphics behaves much better.

Over heat and noise issues with quad core MBP workstations, I've given up and bought two Mac Pros (a 2006 and a 2009), upgraded the CPUs to eight core and six core respectively. The 2006 with Apple AMD 5870 installed is nearly silent (much quieter than the 2009) and multitasks better than the MBP 15". The two silver towers (home and office) cost less combined than a single new MacBook Pro. For now I'm running the 2011 MBP 15" on integrated graphics only as a carry around (no external monitor).

---

This solution targets MBP 15" 2014 Retina model. My own interest in disabling the discrete GPU was for a MBP 17" 2011 model. As an important piece of software for me required Mojave, I recently revisited disabling the discrete GPU. gfxCardStatus doesn't work in Mojave (it will show information but not reliably disable the discrete GPU).

Setting an NVRAM variable worked (nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00). An NVRAM variable also enabled open clamshell mode on a MBP 16" which I have here for testing. Setting an NVRAM variable seems to be a the best and safest way to solve serious graphic card issues on MacBooks.

The full NVRAM solution for the MBP 2011 family was carefully investigated and documented by Luis Puerto. I've successfully executed this solution. In case Luis's site is down, a similar post but wordier is on AskDifferent.

Answer 3

Your planned procedure is possible. Your planned procedure is not that difficult. Your planned procedure is not the best option.

Why this route is suboptimal

MacBook Pros will and have to switch to discrete GPU (dGPU) once an external display is connected. Therefore, an installed but disabled dGPU takes away the option to use an external Monitor with that dGPU.

There are other options now, like using USB solutions or external GPUs (eGPU). But setting the EFI variable you are looking for will definitely disable direct output with one cable from the Thunderbolt port to an external monitor.

How you can disable the discrete GPU from EFI?

The command you mentioned in your update is almost correct. It just misses the proper identifier:

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

This writes the corresponding EFI variable to NVRAM and forces the MacBook Pro to always boot straight into integrated GPU (iGPU). The identifier is not only for AMD dGPUs but all dGPUs. This is confirmed to work with NVidia chips alike. It is also easily reversible with an NVRAM reset.

Disadvantages of this strategy in this situation

And now the downside: There are potentially two little problems with this:

1. After you force these NVRAM settings macOS might get "a little bit confused". The chip is still there, wired and powered.

2. To get this to boot you might need to disable the graphics drivers for your dGPU. Or at least the one kext that manages the actual graphics switching. The boot might hang when trying to initiate GPU switching otherwise.

Both newly arisen problems can be dealt with by moving either all NVidia kexts out of /System/Library/Extensions to a safe backup place. This will boot the machine forced into accelerated iGPU mode. But setting an EFI variable might not be enough to get sensible power management. For that you will likely have to move back the NVidia kexts except those responsible for graphics switching. Failing to do so will lead to needlessly high power on the dGPU. It will at least idle at "full power' (translated to >~60°C).

This high power idle will potentially be the great defeat for your plan to reduce fan noise and increase battery. Side note from the literature: It should be a truth universally acknowledged that moving kexts around also requires that you disable SIP on newer versions of OS X/macOS as long as you move things like this around.

General stratedy to find the kexts to experiment with: boot without the NVRAM variable in a stock system (with 'default' NVidia kexts). Then take note of which extensions your system actually loads with kextstat. Then reboot with previously loaded NVidia/Geforce kexts moved away and the hack enabled. Get a detailed sensor monitor (iStatMenus, TGPro, etc…) and watch the temperature on and around the GPU. Now load one after the other of the relevant kexts back into the kernel with sudo kextload /path-to/NVDA***.kext. Wait one or two minutes after each.

Since the method of this post – or the equally valid but looong way: manipulating EFIvars in Linux – is NVRAM, it will revert cleanly if you do an SMC/NVRAM reset. That NVRAM hacking is actually the only part of this post that for sure will not give you much trouble.

Doing this NVRAM reset restores a minimal set of factory settings to EFI variables/NVRAM. That factory setting will not be touched.

This can be done as often as you like.

In Linux the driver system is much better documented and imho implemented cleaner. There are many ways to achieve this with or booting into Linux. And a Linux (whether respecting this NVRAM/EFIvars setting or through other methods) will give you much less trouble with drivers (Who'd have thought). For other OSes, like Microsoft Windows, I have no data.

To repeat: Having the OS not recognise the dGPU properly does not mean it is powered off. That might lead to unwanted thermal side effects.

Take a look at this guide for 2011 MacBook Pros for a similar solution and a little bit more options; also to quickly undo and redo the NVRAM hack.

Multiple monitors and a disabled dGPU

Having said that all: gfxCardStatus (or try different versions of the original – they have different options/capabilities…) is imho the best option if you do not have real hardware issues to deal with. It's much more flexible and you can still switch back to dGPU or external monitors quite easily within a running system.

Whether via EFI/NVRAM or with gfxCardStatus: forcing a Mac with switchable graphics to integrated-only will disable external display modes using the built-in DisplayPort or Thunderbolt graphics output. This is a consequence of the hardware design which routes the display signal for external monitors through the dGPU. Using not discrete but external graphics adapters might be a workaround for that limitation.

The EFI setting to enable integrated on other operating systems

As should be clear by now, the EFI setting to allow other operating systems like Linux to "see" a switchable graphics setup is different from the above that disables the dGPU. Tiny EFI program for unlocking the Intel IGD on the Macbook Pro 11,3 for Linux and Windows:

Tiny EFI program for unlocking the Intel IGD on the Macbook Pro 11,3 for Linux and Windows. It has been made to be easily chainloaded by unmodified EFI bootloader like Grub, rEFInd etc.

The Macbook Pro 11,3 model's EFI is switching off the Intel GPU if you boot anything but Mac OS X. So a little trick by faking the OS identifiction is required to make all hardware accessible.

All credits belong to Andreas Heider who originally discovered this hack: https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html

Answer 4

Belated answer to one of your side questions: You probably need the discrete GPU enabled to use an external display. The reason why should be in how the GPUs and the video outputs are wired.

(I'm half-guessing, half-extrapolating from how the PC laptop graphics switching technology works. It's not an unreasonable assumption that those technologies are based on the GPU vendors' work with Apple. Still: take the following with a large grain of salt.)

With nVidia Optimus, the setup is that the built-in display of a laptop is connected to the integrated GPU, and the external display port is connected to the discrete GPU. If you need to render stuff using the discrete GPU to the built-in display, the discrete GPU is "slaved" to the integrated one. A rendering call first goes to the integrated GPU, which, if the discrete GPU is enabled, forwards it there, then retrieves the result to push it on the display.

If an external display is connected, rendering calls for that display go directly to the discrete GPU, because that's the GPU that can send any output to that display anyway. The integrated GPU simply can not, at all, send video output to that port on its own. I don't think it's even possible to have the integrated GPU be "slaved" to the discrete one, because first of all it'd be pointless from a design perspective with regards to the goals of the graphics switching technology; and even then, it'd still require the discrete GPU to be enabled, which wouldn't help people whose chip is failing.

Answer 5

If anyone is still looking for ways to do this, please check out this MacRumors forum post.

I followed the steps mentioned in that forum post and my 15" MacBook Pro 2011 is working perfectly using only its Integrated Graphic. The worthless AMD graphic card was disabled successfully.

https://forums.macrumors.com/threads/force-2011-macbook-pro-8-2-with-failed-amd-gpu-to-always-use-intel-integrated-gpu-efi-variable-fix.2037591/page-5#post-24511780

https://forums.macrumors.com/threads/force-2011-macbook-pro-8-2-with-failed-amd-gpu-to-always-use-intel-integrated-gpu-efi-variable-fix.2037591/