Kryptonite: TB1/2 Mac eGPU Support with FileVault, SIP, and ART Enabled
@mac_editor, I tried the latest version and all was well.
@itsage, excellent, thank you. I had replaced all the AMD GPU architectures from the Kryptonite Info.plist (think codeless kext approach) with a single patch, and looks like it does the trick. I believe @goalque used a similar patch in automate-eGPU EFI which allowed legacy AMD GPUs w/o codeless kext. He never disclosed the patch but it was straightforward to figure out as IOPCIFamily code is open source. With this, kryptonite should technically be on-par with the other eGPU solutions while providing a better platform with OpenCore and Lilu along with the security benefits.
As per the checklist in the main post, I believe I have addressed all concerns (waiting on NVIDIA test from @ponqable though) except the NVIDIA dGPU - AMD eGPU problem. I might have to get another mind on board to help resolve this one (probably the friend I worked with for tbt-flash).
The installer remains as well - I've been thinking hard on how I want to approach this, so this might take time.
@itsage, I am not familiar with the GPU architecture differences across the BNavi lineup. The best way to answer that would be to probably try via codeless kext. You can start with this as a reference: https://github.com/mayankk2308/purge-wrangler/blob/master/resources/AMDLegacySupport.kext.zip
Then get the IOKitPersonalities for the drivers that are used for the 6800 XT, and add the device ID for the 6700 XT into those driver personalities via IOPCIMatch field. Throw the codeless kext into /L/E (SIP w/o kext required) or inject via OpenCore - you can refer to Kryptonite config.plist to see how kext injection is configured - pretty similar to how you did it for DSDT.
I could probably set this experiment up if you can share all the kexts the run when the 6800 XT is connected.
Should be enough. Testing on an iGPU-only Mac would make things even clearer.
Update: Apparently the device ID is already present in AMDRadeonX6000FrameBuffer.kext. Maybe it just needs it in some other places. It's absent in AMDRadeonX6000 and AMDRadeonX6000HWServices. I would imagine that AMDRadeonX6000.kext probably needs to implement AMDRadeonX6000_AMDNavi22GraphicsAccelerator IOClass. I did a disassembly and checked but didn't find this symbol. There's obviously already a Navi21 variant (I checked on 11.4). Doubt the GPU would work as is but it's not too hard to experiment with the Navi21 driver so I'd try anyway.
@mac_editor, Would you mind taking a look at the kext to see if Navi 21 XTXH support is there? Regular Navi 21 XTX's ID is 1002 73BF while XTXH's ID is 1002 73AF. 99% sure they can use the same driver so it's just missing an device ID for support.
@kid, oh nice, if only the device ID is different it could technically work. I checked all 3 kexts and 73AF was indeed absent. There was also this issue: https://github.com/acidanthera/bugtracker/issues/1618
There is nothing of interest within the kexts although I did not do a deep dive. I don't understand why (as mentioned in link above) people were trying to spoof card to be 73BF instead of adding device ID via IOKit impersonation via codeless kext.
@itsage @kid @mkzayar Injecting this kext via OpenCore should add the necessary IDs for XTXH and Navi22. I don't expect the latter to work, but XTXH potentially could. I don't have either type of card to test anyway so I'll leave it to whoever wants to test.
@mac_editor, Thank you for making these requests! I got a bit excited and installed macOS 12 Beta last night on several Macs (2015 21-in iMac included). It seems Lily doesn't work well with this macOS version yet. Here's my output in the log file.
I will test on the 2015 15-in MacBook Pro and report back.
@itsage, You need to enable the kexts in beta by adding -lilubeta and -krybeta boot arg in config.plist. The kexts automatically get disabled on beta systems (when major kernel version changes).