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

Solution 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!

Solution 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.

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

  2. 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

  3. 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.