[Sticky] [APP] eGPU Enabler by Rastafabi
The alternative eGPU guide (macOS only)
Whom is it for? - Professionals and amateurs requiring compute power using NVIDIA eGPUs, as well as people who want to drive additional displays and gamers.
Whom is it NOT for (yet)? - AMD eGPU users. They should check this out.
Thunderbolt Macs (Thunderbolt 1 and 2 works, 3 untested)
- MacBook Pro 13" (2011 - present)
- MacBook Pro 15" (2011 - present)
- MacBook Air 13" (2011 - present)
- Mac Mini (Mid 2011 - present)
- iMac 21" (Mid 2011 - present)
- iMac 21" 4k (Late 2015)
- iMac 27" (Mid 2011 - present)
- iMac 27" 5k (Mid 2014 - present [limited support - read on])
- Mac Pro (2013 [untested])
- GTX 7xx (Ti) - Kepler/Maxwell architecture
- GTX 9xx (Ti) - Maxwell architecture
- GTX 10xx (Ti) - Pascal architecture
- GTX Titan (xx) - Kepler/Maxwell/Pascal architecture
- Always use the latest macOS version. Should work from 10.9.5 onwards. Compatibility with 10.12.5 confirmed.
To properly set up your eGPU enclosure search the forum. I'm pretty sure it's already covered. Using multiple eGPUs should work but needs to be tested.
- READ THE ENTIRE GUIDE
- Download this installer:
- Run it (right click - open, if macOS blocks it)
- Follow the onscreen instructions
Important Information (READ_ME):
- The package will purge any of it's previous versions, so you can just install it.
- You can disable monitor out support in costumisation section of "Installation Typ", if you do not need it. This also solves the login screen issues of the 5k iMac.)
- You should not use my package and goalque's script simultaneously.
- Many thanks for all the testers! - Especially DANgerous25 for his persistent retestings (I know it sucks). He also put up a guide dedicated for 5k iMacs.
- The default scaled retina resolution (2560*1440) won't be applied to 5120*2880 anymore, but only to 3840*2160. This difference is noticeable. You would need to judge whether your okay with this yourself. This is currently under investigation.
- If you have a 5k iMac you MUST have an external display or FileVault enabled to see the login screen! Refer to the guide linked above.
- If you disable monitor out in the costumisation section while installing my package you won't have those issues.
- Files being installed (for reference):
Just launch the "Uninstall Rastafabi's eGPU Enabler.app" from the applications folder.
- Read this thread.
The driver should survive software updates. This was confirmed with the 10.12.3 and 10.12.4 to 10.12.5 update as well as various NVIDIA driver updates. However it is not guaranteed for future ones.
If it does not work after upgrading try running the following command in terminal (it might help, maybe):sudo nvram boot-args="-ngfxbeta -lilubeta"
Edits (except minor ones):
Post updated to better serve as a guide.
eGPU.kext updated to reflect changes from here
Package installer added. No need for manual installation anymore.
9th May 2017:
Package installer updated:
- Now supports disabling monitor out support
- Fixed an issue for iMac 5k users when they temporarily booted without an external monitor
Post completely updated
The Driver (same file as linked above):
Use at your very own risk! I'm NOT responsible for your data security, any hardware damage, any software issues, any data loss, or any other issues related and unrelated to my uploads.
Interesting. I assume you noticed the last paragraphs 😉
Life is much easier without kext modification.
Apple requires a special Developer ID:
"Kext signing requires a special Developer ID Application signing identity with the custom extension with OID 1.2.840.113618.104.22.168.18. You can see this in Keychain Access if it's present. Otherwise, the identity is valid for signing apps only."
Well, I did. And circumventing the kext modification procedure altogether would be marvellous (something costumer-ready in the pipe?). My simple driver doesn't actually do anything different than modifying the kext, but it does so on the fly (kext keep their signing certificate). Right now this procedure is an extremely simple way to avoid system update dependent (automatic) rerunning of the script.
BTW: The exact same technique to force loading the NVIDIA driver, though it is not natively qualified for PCI tunneling, should work to inject the needed modifications into the AppleGraphicsDevicePolicy.kext as well as any ATI/AMD driver. The kext generation itself could even be automated using a script, as the kext actually does not include any code itself. That being said I failed to enable display out. (Apart of one try which was not accelerated, but which I lost after adding additional modifications and which I did not backup.) However it IS possible somehow.
The pro side of this Dummy.kext injection technique obviously is, that it is persistent across reboot, with the only letdown right now, that disabling SIP (partially) is still required.
PS: NVIDIA Web Driver installer repacking is not needed ever since NVIDIA introduced "experimental MacBook Pro and iMac support".
I assume, that your EFI application works in a similar way as my driver, doesn't it? I also experimented with pre-boot kext-patching using clover, but I disliked that way due to all the negative clover related side-effects on legit Apple hardware. Also I haven't been able to compile clover reduced to being refit with kext patching.
Do either of your methods allow for use without an external monitor? I suppose that is my main concern with this idea: I simply need the GPU for 3D horsepower. If this is possible I suppose my next question is would any 3D app see the eGPU or do other factors depend on that? The apps in question are: Cinema4D, After Effects, Substance Painter, vRay, Thea Render.
Thank you very much.
The procedure in post 2 discribes exactly what you need. It allows the use of the eGPU for rendering and other GPU related CUDA and OpenCL task for applications which support selecting a specific renderer (like Premiere/Aftereffects and similar).
It does not allow the use of external monitor.
Yep, it is a codeless kext:
I have done something similar. If I had no fulltime job, I would surely devote my time to EFI and kext programming.
UEFI doesn't allow writing on Apple's HFS+ partition (it returns error code EFI_WRITE_PROTECTED) so a kernel extension or in-memory substitution are the only ways to make kexts IOPCITunnelCompatible, SIP enabled. As it seems that Apple has made it much more difficult to get TB3 AMD eGPUs working in Sierra, forced the Internet recovery to 10.12.3 and new firmwares, and they plan to release APFS as a bootable filesystem this year, I don't expect that we would see 3rd party software eGPU solutions in the pipeline near future.
I like the idea of enabling the eGPU with a codeless kext, because all the edits required can be joined into a single plist file. Once someone has the time and is willing to write a fullfledged codeless kext injecting all the necessary values this should turn out to be an easily maintainable solution.
If the EFI prohibits writing to the HFS+ partition, (and later on to the AFS partition, if any driver will be written anyway) how does the clover kext-patching work, which even injects the code into the kernelcache as far as I know. Also the Clover kext injection might be an interesting starting point. A rather "simple" EFI chainloader with those functionalities could be useful. If I got it right, your implementation goes far further. (Just to mention the EFI-ROM loading.)
HFS+ partition is not writable, but it is readable from EFI. The startup manager and bootloader are EFI binaries among others. AFAIK, Clover uses customized kexts, utilizes the kernel cache and then Apple's boot.efi takes care of the rest. Apart from ACPI table installation, I've not yet looked at Clover source code more in-depth. Another way is to emulate the process of boot.efi and modify/load kexts on the fly but that involves lots of reverse engineering.
I don't like hacks. A codeless kext is a good approach because it doesn't modify any system files. Instead of "Kext Utility.app", I would just place the kext into /Library/Extensions/ and set the proper permissions/ownership from the Terminal. I've not tried out your kext, but I am sure that it works. As you said, it doesn't do anything different than plist modding, doesn't solve TB3 problems, but is much cleaner way.
Since Apple didn't came up with significant blockers for Thunderbolt 1 & 2 eGPUs until now, I doubt they ever will - even less likely with a minor OS update rather than a release. While external displays eGPU has not been available in early 10.12.4 betas (related to NVIDIAs drivers) output hat been available though. Haven't checked Cuda back then - nor I have tried any recent betas at all. Keeping the fingers crossed.
About your Adobe Suite issue: If I remember correctly it's possible to assign "unsupported" Cuda renderers - just google it. It might involve some terminal magic but last time I needed this (pre eGPU times) it wasn't too hard.
Having dual eGPU should work unrelated to having multiple Thunderbolt controllers. Even bandwidth could be a minor issue, as non is used for out screen output. With output doubled bandwidth with Thunderbolt 3 isn't an improvement in terms of benchmark scores so dual Cuda could work without major performance drops on Thunderbolt 2. If you can't find any reference to such a setup online testing is up to you.
Of course the next questions are: Can a Mac Pro Trashcan handle 6 eGPUs + the built-in FirePros? And is that really the best option we have for lots of GPUs?
...also, I feel this thread ought be stickied somewhere so that other people that simply need CUDA on existing setups can find it easily.
Two further questions:
1. What are the repercussions of running more than one eGPU per bus? My layman understanding of this barefeats article makes me believe having two units per bus would not cause significant performance loss (in CUDA apps at least).
2. Is there a limit to what MacOS can handle? This appears uncharted territory but I'm certain someone somewhere has been running multiple GPUs using a PCIe expander on the old 4,1 and 5,1 models.
I've seen 4+ GPU setup with the older Mac Pro towers via an PCIe expander. Mac OS had no problem detecting them. There's a point of diminishing returns though. IMO if you'd need multiple GPUs, eGPU is not the best solution.
I'm currently running my main Mac Pro tower with 3x RX 480s. This is an older photo with an RX 470 on top.
Using my driver you need to run the following Terminal command and reboot after the 10.12.4 update to reflect the build number changes:
export BuildVersion="$(sw_vers -buildVersion)" | plutil -replace IOKitPersonalities.NVDAStartUpWeb.NVDARequiredOS -string $BuildVersion /System/Library/Extensions/eGPU.kext/Contents/Info.plist If it still does not work after rebooting you might need to rebuild the kernelcache. Just run the recommended application from post 2 to do this.
Edit: Updated the command to be universal and future proof. Could be added to a launchd script bundled with a installer coping the the kext, setting permission and rebuilding the kernelcache. Or does anybody know a way to use variables in Info.plist files?
Obsolete - Driver has been updated.
Using my driver you need to run the following Terminal command and reboot after the 10.12.4 update to reflect the build number changes:export BuildVersion="$(sw_vers -buildVersion)" | plutil -replace IOKitPersonalities.NVDAStartUpWeb.NVDARequiredOS -string $BuildVersion /System/Library/Extensions/eGPU.kext/Contents/Info.plist
If it still does not work after rebooting you might need to rebuild the kernelcache. Just run the recommended application from post 2 to do this.
Updated the command to be universal and future proof. Could be added to a launchd script bundled with a installer coping the the kext, setting permission and rebuilding the kernelcache. Or does anybody know a way to use variables in Info.plist files?
@Rastafabi thank you for your contribution! If you can work with Goalque to further develop automate-eGPU script into an installer of some sort, that would be wonderful for the Mac eGPU community.
We have been in contact some moths ago but nether actually talked about joining forces, especially as he handed over the script work to focus on EFI development. Also my work so far focused on a different approach but indeed could reuse some other his scripts data. So far I still experience problems injecting patches into the AppleGraphicsDevicePolicy.kext which handles the eGPU screen output. Also the above issue remains to be solved because a non-static info.plist would prevent the kext from ever being signed and "just work", though a solution close to that (disable SIP, install once and just forget because it will work) could be achieved. The total implementation effort for this even is rather basic but extremely time-consuming. Time most of us here do not have. Also my programming knowledge is at the best basic when it goes further than scripting and bash.
Apart from that, the recent 10.12.4 update could turn out to be bigger news than expected, because apple just enabled support VT-d for (Thunderbolt) Macs (~PCI virtualisation support, supposedly elementary for AMDs XConnect and NVIDIAs eGPU hot-plug solution; VT-d was supported by Mac Pro, Xserve [and iMac?] since a decade, while at least MacBooks and Mac Minis weren't). Even without I already managed to enable screen output without having to restart, but I couldn't get acceleration, nor unload the eGPU without crashing the system. That being said DO NOT expect any macOS eGPU hot-plug related development within the community anyway, as this would need proper driver implementation, thus being Apples, NVIDIAs (and AMDs) part.
@Rastafabi, I've linked your post as an alternative method in my automate-eGPU.sh thread starting post. A good starting point for those who are willing to integrate this into the automate-eGPU.sh script and simplify it.
Remember that Nvidia drivers are tied to macOS build number and if the underlying dependency kexts have changed after macOS upgrade, replacing the NVDARequiredOS might not be sufficient. Security updates can also break driver functionality. It's recommended to wait for the new web driver release.
The Internet recovery brings a completely new build 16D30 (at the time of macOS 10.12.3). Apple doesn't say anything about this. It is missing from Wikipedia's build list ( https://en.wikipedia.org/wiki/MacOS_Sierra ). The script doesn't find it because Nvidia is not aware of this build number. However, by replacing the NVDARequiredOS, the web driver meant for macOS 10.12.3 works in the initial macOS Sierra environment.
@Goalque, thank you for linking this to your thread, though it might be better to add, that it's not supposed to get screen output, yet. I know that the NVIDIAs drivers build dependencies have a purpose, of course, but the injection I'm currently doing is not supposed to circumvent this (it's just side-effect). However I had kernelcache corruption issues injection only selected values rather than the whole IOKitPersonalities blog. That's why this is included in my codeless kext, although it is complicating the approach to write a universal tool.
EDIT: I tried again without injecting the build number values and so far it runs stable. This might work out to be a final solution to make the kext OS update independent ("just works"). So to test this you can execute this command in Terminal:
plutil -remove IOKitPersonalities.NVDAStartUpWeb.NVDARequiredOS /System/Library/Extensions/eGPU.kext/Contents/Info.plist
Obsolete – Driver has been updated.
Seeing as certain apps behave differently depending on the type of GPU they can recognise (i.e. AMD best for FCPX and Nvidia for CUDA, etc) I have a question regards the use of dual eGPU set-ups. I have a MacPro trashcan and thus theoretically could run up to three eGPUs (one per bus as per theitsage's post above). If I do, will the Apps automatically detect the right card for them or is some other manual intervention required? i.e. if I have monitors attached, say one on an R9 Fury and one on a 980Ti, will I need to launch the app on the relevant display? and, if I don't have monitors attached, will some form of script be required in order to get the app to recognise the card - like Rastafabi's solutions in Post 2?
Right now it IS NOT posible with muy solution to connect monitors! It's only supposed to be used as an OpenCL and/or CUDA accelerator. And currently not for AMD grafics but only for current NVIDIA GPUs.
Concerning application support it really depends on the software your using. Best thing would be to ask the developer wether it is possible to manually select a/multiple GPU/s for acceleration. While some applications default to the the default screens current accelerator others default to the most powerful one while some applications just use everything they get which is OpenCL enabled. There is no pattern to determine the software's capabilities.
(Shouldn't we start a thread for software support and possible workarounds.)
Good call. I would appreciate knowing how best to configure host systems for various differing usage cases. Very useful response though - many thanks. Can't wait to get my Venus and get cracking. That said, does anyone know if the 'shipping' version will have resolved the issue of 1/2 speed CUDA performance?
I recently purchased a Razer core and a 980ti. After searching and sifting through a lot of threads I think this aligns to what I want to do. I just want to be clear before I start running scripts etc. This solution is for users who want to use an internal display to boost applications like adobe CC and using nivida cards? Thanks for your time and apologies for the noob question. I switched from PC to Mac and don't want to go back to windows 10
Here are my steps for upgrading a system that already uses Rastafabi's eGPU.kext to 10.12.4.
- Upgrade to 10.12.4
- Upgrade Nvidia and CUDA drivers
- Run Rastafabi's terminal command in this post
- Reinstall existing eGPU.kext using Kextutility
...I have no idea which of these steps are necessary, but it works, and is necessary (the eGPU was not seen after upgrading). Perhaps someone can write a concise guide we can put in the original post.