[APP] NVIDIA eGPU support for High Sierra (NVIDIAEGPUSupport)  

Hi, @soulwash, I will also try to downgrade... Do you know the steps of downgrading, I can not find the "macos high sierra 10.13.3 installer"... only find some updates of 10.13.3.

I've to say that I've not played with Nvidia cards for several months because being in the endless patching loop is not very fruitful. Glad to see that a few people still have strong motivation in exploring these hacks, and my clue about AppleGPUWrangler as the culprit turned out to be true.

As to eGPU screen output, my first attempt also failed. Don't stop there. Try again, different cables and monitors. Do not use any other display adapters except Apple's TB3/TB2 if you happen to have a TB2 Mac.

After rebuilding caches using the method from my old automate-eGPU.sh, a couple of restarts, it is close to perfect on macOS 10.13.4. Just keep the eGPU plugged in from the beginning. If you happen to have the notorious 2015 13" that rejects newer Nvidia cards on startup, hot-plug during the early boot process. If the Apple logo shows up on the eGPU monitor, it is a sign that macOS is set to run eGPU monitor as the primary. If not, the internal screen is the primary display. This setting can be also changed programmatically, in C/C++. Maybe in Swift as well. Some years ago I made an app that switched the white bar location. Not possible by the script AFAIK.

I tested with two different TB2 MBPs, all display interfaces (HDMI, DP, DVI) worked, two different monitors, including 4K. Of course, no eGPU surprise removal support with Nvidia even though it shows a list of processes that need to be closed.

The remaining symptoms are caused by the older AppleGPUWrangler from 10.13.3 which results in
1) slower startup process
2) inability to change AMD dGPU (M370X in my case) to drive the internal display (automatic graphics switching always turns on, and if you try to uncheck, and logout, the internal screen goes black). Iris Pro is always active. However, apps like Valley correctly attach to M370X (iGPU+dGPU combo, no eGPU attached) and you can verify it in Activity Monitor > Window > GPU History.

No other issues. OpenCL, OpenGL work fine. Haven't tested any TB3 Mac yet.

Good job @fr34k

@goalque
Nice, comprehensive and detailed report!
So rebuilding caches (like in your old script) helps with the external monitor problem? If so I could add those 2 additional lines (+ tests) to the script.

Posted by: goalque

 

If you happen to have the notorious 2016 13" that rejects newer Nvidia cards on startup, hot-plug during the early boot process.

Early or late 2016? I guess you meant the TB2 one?
I have tried this on my late 2016 TB3, doesn't solve the issue. The display tab in About indicates the iGPU is attached to the internal display. Is there any way to switch manually or force the eGPU to the internal display?

Posted by: Arthy

Posted by: goalque

 

If you happen to have the notorious 2016 13" that rejects newer Nvidia cards on startup, hot-plug during the early boot process.

Early or late 2016? I guess you meant the TB2 one?
I have tried this on my late 2016 TB3, doesn't solve the issue. The display tab in About indicates the iGPU is attached to the internal display. Is there any way to switch manually or force the eGPU to the internal display?

Early 2015. It was a typo, just corrected.

Ignore "About > Displays", that info is not always up to date. Set the eGPU monitor as the primary (white bar on top). Go to Graphics/Displays > click on the video card and press Command+R === more reliable result which GPU runs which display.

Posted by: fr34k

@goalque
Nice, comprehensive and detailed report!
So rebuilding caches (like in your old script) helps with the external monitor problem? If so I could add those 2 additional lines (+ tests) to the script.

Thanks! Not sure yet. See RebuildCaches() function:

 echo "Rebuilding caches..."

 if [[ $(test -f /System/Library/PrelinkedKernels/prelinkedkernel && echo 1) ]]

 then

 rm /System/Library/PrelinkedKernels/prelinkedkernel 2>/dev/null

 fi

 if [[ $(test -f /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache && echo 1) ]]

 then

 rm /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache 2>/dev/null

 fi

 touch /System/Library/Extensions

 kextcache -q -update-volume /

 touch /System/Library/Extensions

 kextcache -system-caches

The eGPU display was black first, but after a few tries no issues anymore. Just very slow startup, with both MBPs.

@goalque
the last four lines I have in my script it's only the first two rms that I don't have implemented.

Posted by: fr34k

@goalque
the last four lines I have in my script it's only the first two rms that I don't have implemented.

Those rms were important when I rebuilt AMD eGPU kext caches. Verify that paths still exists in macOS 10.13.4, and macOS regenerates these files. Sometimes a double reboot was necessary.

Kext-swapping method is nice when it works, but just like the TB1/2 patch - it may just suddenly not work on later versions of macOS. So in summary we have (pls correct if wrong - my testing has too many variables (750M, TB2) to make precise deductions):

• NVDAEGPUSupport + 10.13.4 AppleGPUWrangler (Patched or not) = Incompatible
• NVDAEGPUSupport + 10.13.3 AppleGPUWrangler = Works
• Different versions of NVDAEGPUSupport needed per OS version -> automation across updates possible - same kext can be managed with a binary and its OS version and driver references fixed on update

So should we:

• Invest time in creating a very stable script for NVDA support on 10.13.4+ while automating NVDAEGPUSupport install (could add to wrangler patcher) based on this replacement strategy <- Doable
• Invest time in creating a new NVDAEGPUSupport compatible with the new OS <- Hard
• Invest time in reverse-engineering macOS <- Hard af

Reversing really requires more man-hours and luck vs. scripting...

Posted by: goalque

Those rms were important when I rebuilt AMD eGPU kext caches. Verify that paths still exists in macOS 10.13.4, and macOS regenerates these files. Sometimes a double reboot was necessary.

Double reboot typically happens if before first reboot caches were not built/were incompletely built. Kextcache commands should technically suffice in my opinion, but yea, as I've said multiple times - the kextcache command is kind of messed up on HS (reported as well).