[Solved] The Mac Pro (nMP, 6.1, 2013, Trashcan) eGPU Setup Thread
I just wanted to offer up my experiences getting the nMP (Mac Pro 6.1; Mac Pro 2013) running with an eGPU on Bootcamp. Partly because it was a bit of a struggle to find concrete info about the Mac Pro and partly because, as of right now, I'm not entirely sure what I did to get it working, or whether the process I went through is fully documented. I am not, by any means, an expert with the deep, inner workings of MacOS or Windows, but I'm hoping that others might be able to shed some light on it.
My build is as follows:
- Mac Pro 2013 running Intel Xeon E5-1650 @ 3.50Ghz
- Dual AMD FirePro D700
- OWC Mercury Helios FX eGPU enclosure
- Radeon RX 580 8GB
- Apple Thunderbolt 3 to Thunderbolt 2 adapter
- OWC DriveDock (USB C) with SATA HDD running Windows 10
- Belkin Thunderbolt 2 dock
- MacOS Mojave (10.14.6)
- Windows 10 Pro (1809)
- automate-eGPU EFI, running on a USB stick
To begin, getting the eGPU working under MacOS Mojave was trivial - standard procedure of running automate-eGPU with no problems whatsoever. Windows 10, however, is a totally different story.
From what I could tell, the Mac Pro was unable to properly use an eGPU enclosure due to a firmware quirk that prevented proper access to them. The last mention of the Mac Pro in this forum that I could find (and please, correct me if I've missed something) were users trying to overcome Error 12 on the eGPU or Error 43.
Initially, I got Error 12 on the RX 580. I used the pre-compiled DSDT override to get past that and then got stuck on the classic error 43. Drivers wise, I DDU'd everything off the machine and used the bootcampdrivers.com version of the Radeon drivers. No change to error 43.
I left it for a while as I figured it just wasn't possible to get eGPU working. Then, out of what I assume is an act of wanton cruelty and stupidity, I decided to dive into Device Manger and start disabling some PCI-to-PCI Bridge devices in there, taking (somewhat little) care not to disable ones the eGPU sat on. I disabled five of them and rebooted and... it worked. Error 43 was gone and all three GPUs are now working.
In order to get the machine to actually use the eGPU, I have to physically plug my monitor directly into it. The graphics performance options in Windows 10 doesn't show the Radeon RX 580 as the high-performance option, possibly because it picks up the second D700 and thinks that's the high end option. When the monitor is plugged directly into the RX 580 though, the performance options only show that card. The Radeon Settings app also changes to show the RX 580 as the Primary/Discreet card, with the two D700s appearing as well as Discreet options.
And it works. Loading up Arkham Knight (currently the most GPU taxing game I have on my system right now) shows the RX 580 being used, with full access to its 8GB of VRAM. If my monitor is plugged into the Mac Pro directly, it reverts back to the D700s, with the expected performance hit.
So, now I have some questions!
- Why does this work? Has it been fully documented with regards to the Mac Pro?
- What exactly have I done in disabling some of those PCI-to-PCI Bridges?
- Has anyone else had the same success?
- I'm running Windows 10 externally on a SATA HDD. This is connected via the OWC Drive Dock, which is running into a Belkin Thunderbolt 2 dock via USB 3. In order to get this aspect working correctly, I had to transfer a copy of the EFI file for Windows off that hard-drive and onto the automate-EGPU EFI thumb drive. The boot process currently involves powering on the Mac Pro, selecting the thumb drive, powering up the OWC Drive Dock and letting the Windows HDD spin up for a few seconds before selecting the Load Windows option in automate-EGPU.
- In terms of the Windows installation itself, it's a bit of a Frankenstein nightmare. The drive was pulled out of my old Mac Pro 5.1 tower. I've removed as much of the old machine from it as possible and loaded fresh Bootcamp drivers using Brigadier. At some point, I'll format it and do a fresh install, but it's not viable at the moment.
I'm more than happy to provide more technical information if needed/requested!
Why does this work? Has it been fully documented with regards to the Mac Pro ?
@aj_scarcella Code 12 usually implies there aren't enough resources to allocate the PCIe device. Error 43 has myriad causes. Disabling PCIe devices frees up resources. No we don't have any documented solution for Mac Pro 2013 Bootcamp - this would be one if reproducible.
What exactly have I done in disabling some of those PCI-to-PCI Bridges?
Freed up precious resources for PCIe device allocation. If possible please share what all items you disabled. Also share your bootrom information from System Report in macOS. @itsage would definitely be interested in this. Are you by chance using apple_set_os.efi (which comes by default with automate-eGPU EFI) as well?
Has anyone else had the same success?
Not on this forum, I don't think so.
Thanks for the reply!
These are the PCI-to-PCI Bridges I disabled:
- PCI bus 17, device 10, function 0
- PCI Slot 2 (PCI bus 95, device 4, function 0)
- PCI Slot 4 (PCI bus 21, device 5, function 0)
- PCI bus 21, device 0, function 0
- PCI Slot 2 (PCI bus 95, device 1, function 0)
This was done (as I mentioned, stupidly) at random. Let me know if further information is required out of Device Manager. I should note that I have not noticed any bizarre behavior as a result of disabling these devices. The eGPU is plugged into the bottom left Thunderbolt port, as per recommendations in other threads. The top left port works fine to drive my LED Cinema Display (which defaults to using the D700 GPUs, as mentioned) and the middle left port is driving the Belkin Thunderbolt Dock (which is working because Windows is running off that port right now). I'm only running a single monitor, but dual monitors definitely works (combination top left Thunderbolt port and HDMI directly out of the eGPU).
Boot ROM version is 126.96.36.199.0. This is a relatively fresh install of Mojave as well.
I didn't think getting it up and running was a common thing, so I want to figure out exactly how to replicate it in case I need to start again with Windows.
Are PCI bus numbers sufficient for recreating this? Bus numbers can change, depending on the software that enumerates PCIe devices. I think you need vendor and product IDs of each device to be sure. If they are not unique, then you may need to know the parent devices at least up to a unique ancestor.
You're right, they're probably not enough. I will try and get more information out of Device Manager later tonight (I'm physically in a different location at the moment with the Mac Pro but not the eGPU). I'm not the most experienced with all of this, but if you let me know which values out of Device Manager you want, I can grab them.
I should also mention that I'm currently booted into Windows 10 without the eGPU connected (i.e. a standard Bootcamp boot, no automate-eGPU EFI) and Device Manager only shows a single disabled PCI-to-PCI Bridge (specifically PCI bus 17, device 10, function 0). I have nothing plugged into any of the Thunderbolt ports at the moment (display is being outputted through HDMI).
@aj_scarcella Welcome aboard and amazing first post! I’m wondering if the new firmware of the 6,1 has exposed the PCIe components through Thunderbolt connection better in Boot Camp. My 6,1 is now running 188.8.131.52.0 due to macOS Catalina. I will it a try soon in Windows Boot Camp. Can you take a screen capture with several instances of Device Manager open to show these information?
It’s possible to disable one of the FirePro dGPUs in Windows so that Graphics Options detects only one dGPU and one eGPU. I forgot the exact arrangement of PCIe root tree in Windows for the 6,1 but you can expand them all to identify which D700 has a Display attached. Here’s the block diagram of the 2013 Mac Pro for reference.
Many thanks! I thought this would be pretty interesting news to this forum. Plus, I really do need to figure out a concrete method of replicating it so I can safely wipe Windows in the future. Here are the screenshots:
(Am I missing an image upload option for the forum or I am just daft?)
And some bonus images:
Arkham Knight graphics settings
@aj_scarcella Very nice to see a working eGPU in Boot Camp on the 2013 Mac Pro. Did you download and use the [Apple_2013_MacPro.zip] from the Nando4 created DSDT overrides from noted user’s system DSDT dump (dsdt.dat)? I will install Win10 1809 on my trashcan later tonight and see if I can replicate your success with the use of automate-eGPU EFI + pre-compiled DSDT.aml. I currently use a very similar process with the 2016 15″ MacBook Pro.
@aj_scarcella I have good news. I was able to replicate your success on my 2013 Mac Pro [Boot ROM version 184.108.40.206.0]. The three PCI-to-PCI Bridges I disabled were under PCI Express Root Port 1a – 0E02. I could leave the second D500 dGPU enabled or disabled and it made no difference to the eGPU detection. I believe the changes Apple made to the trashcan firmware made this possible. Thank you for this discovery! Here are some screen captures.
This is amazing! I guess we can tentatively assume that the full release of Catalina won’t do anything to damage this newfound success.
Are you game enough to try Windows 1903? I deferred this update the other day as I’ve noticed anecdotally that there are eGPU issues with it so I haven’t checked what, if any, solutions apply to the Mac Pro.
@aj_scarcella I believe so. I installed the GM build of Catalina two days ago so there won’t be any changes to the 6,1 firmware until another release. It’s funny because my 2013 Mac Pro was near death due to a firmware corruption. I got it fixed last week and thanks to your discovery it’s now in the best shape regarding eGPU use since I’ve owned it. 😀
We’d love to see your build guide once you have a chance to do it.
@mac_editor I’m doing a clean Boot Camp installation of Win10 1903 as we speak. I’m confident the firmware should allow it to work the same way. Last time I tried Boot Camp eGPU with the 2013 Mac Pro was more than a year ago and I never got eGPU detection. With the latest firmware, detection was immediate. Error 12 & 43 were the hurdles but automate-eGPU EFI, pre-compiled DSDT, and PCIe disablement take care of these errors.
Will do. I’ll look at re-enabling my PCI bridges and disabling the same ones as @itsage.
Out of curiosity, do we have any idea what kind of flow on hardware effects disabling those devices has? Does it stop some Thunderbolt ports from working or something? I don’t have any additional Thunderbolt devices I can run into the system at the same time as the others.
I also want to get Paragon’s APFS driver and see if Windows detects the internal SSD. Not a critical element by any stretch, but I would definitely like to confirm whether or not there is a specific hardware cost to disabling the bridges.
@aj_scarcella Earlier OS Build of Win10 1903 (up to 18362.295) actually improved eGPU hot-plug for many Macs. The 2013 Mac Pro has always been neglected so we don’t really know what works until we try. It’s encouraging to see Thunderbolt device detection in Windows with the latest nMP firmwares.
OK so my two-penneth...
My build is as follows:
- Mac Pro 2013 running Intel 6-core Xeon E5-1650 @ 3.50Ghz
- Dual AMD FirePro D500
- Razer Core X eGPU enclosure
- Sapphire Vega 56 8GB
- Apple Thunderbolt 3 to Thunderbolt 2 adapter
- FLEXX SSD attached via USB running Windows 10 Home (1903)
- MacOS Mojave (10.14.6) (Boot ROM 220.127.116.11.0)
- Win10 drive created using Parallels and Win2USB to mod the EFI partition
I successfully followed the steps in:
i, ii, iii then Option 1: Intel Method i, ii, ii, iv
Note my own DSDT-modified.dsl compiled without error after one change so I did not need to use the pre-compiled one.
Option 1: i, ii, iii
I then had Code 43 and started to disable PCI-to-PCI Bridges. I disabled:
- PCI bus 17, device 10, function 0
- PCI Slot 4 (PCI bus 21, device 5, function 0)
But could not find the others identified by @aj_scarcella
So I randomly disabled and spent many hours watching a black screen followed by Windows auto-repair cycles.
Maybe its the Boot ROM, maybe the Win 1903 build but have given up for now.
So, I think there’s a Windows issue here more than a hardware/firmware problem. 1903 seems to be universally problematic for most eGPU setups, regardless of prior success or complications. Something Microsoft did in it, particularly the final shipping version of 1903, has broken it.
At the very least, we can confirm that the Boot ROM versions in Mojave and Catalina have changed to the point of recognition in Windows 10, and to the point of full success in versions of Windows 10 (notably 1803).
@jcp-123 I don't suppose you have the option to rollback your Windows 10 version?
Have spent today updating to Catalina (Boot ROM 18.104.22.168.0) and trying to roll back Windows 10 from 1903 to 1809 (zero success).
Very useful instructions here: https://pureinfotech.com/download-windows-10-1803-iso-file-after-1809-releases/#download_windows10_1803_iso_chrome
However this means rebuilding my Bootcamp drive and starting again...
Just to confirm your full process... what if any steps did you go through BEFORE you got to DSDT overide? Did yoi implement any of the steps in this guide: https://egpu.io/forums/mac-setup/2016-macbook-pro-solving-egpu-error-12-in-windows-10/#post-709
Spent all day rebuilding my external SSD / Windows 10 drive. A couple of points to note:
- 1803 ISO is no longer available from microsoft downloads (wish I had kept my old ISOs!). I used the 1809 ISO image
- I use Parallels / Windows VM and a tool called Win2USB to create a 'Windows to Go' external drive. Win2USB is no longer free. There are other tools like Rufus and UNetbottin that might do the job
- I really wish I'd saved a 'Restore Point' so I could have rolled back!!!!!!!!!!!!!
- Win10 drive now running Windows 10 Home / 1809 build 17763.379
- downloaed BootCampDrivers latest and applied - no change
- disabled variety of PCI bridges - no change or black screen
Back where I started and am now stumped.
@jcp-123 You don’t need to compile the DSDT file yourself. @nando4 had done it for us so you can simply download it and placed in @automate-eGPU EFI directory. I have not put together a build with step-by-step instruction but it’s a similar process to my 2016 15″ MacBook Pro build detailed here.
I tried the library version dsdt file but it did not work for me. I reverted to the one I compiled and this does work i.e. 'large memory' is created and the Vega 56 is recognised (but hits error 43).
For the dsdt I do not use 'automate-eGPU EFI' as I understand that has a higher risk factor and is more complicated. Am I missing something from NOT using it?
I’m not aware of any risk factors with using automate-eGPU EFI - am I missing something?
In terms of my process, I used automate-eGPU EFI on an external USB drive. I removed apple_set_os.efi, as Windows would not boot properly without it. I had my eGPU switched on at startup, which automate-eGPU EFI recognised. Under Windows, without a DSDT override, my eGPU appeared as an error 12.
I did not follow any of the steps on that error 12 post as most of them aren’t relevant to the Mac Pro. Once I dropped the pre-compiled DSDT file onto the automate-eGPU EFI thumb drive, the eGPU in Windows came up with an error 43 instead of 12. From there, I did my random bridge disabling and after rebooting had a fully functional eGPU in Windows.
So, in terms of differences in our setup, there’s only a few things I can think of. For one, I’m not using Windows2Go - I can’t remember exactly how I fresh installed Windows 10 last time but I don’t think it was through Bootcamp. I think I created a boot disc that had an EFI so that my old Mac Pro picked it up during startup. From there, I ran the installation off the disc and installed it to what was previously an internal drive. I have no idea how I’m going to do a fresh installation on the nMP as something tells me that the installer probably won’t load a Thunderbolt driver. I could potentially get lucky and run the drive dock directly into the nMP via USB, but who knows at this point.
(Ignore 'risk factor' that was me getting confused between automate-eGPU and a method that involves changing the Mac's own EFI partition).
I have now tried automate-eGPU and I like its simplicity. Only problem for me is it freezes as soon as I select the boot OS. This may be because I have upgraded to Catolina (after two days work downgrading Win10!!!)
This is looking hopeless and maybe hex's all Bootcamp eGPUs on Catolina Macs?
Catalina did not affect Windows bootability for me but Catalina itself does not boot using the EFI stick.
Yeah, I think we’re waiting on an update to automate-eGPU EFI for Catalina support. I’ve held off upgrading to it for the time being.
Speaking of the Mac’s EFI partition, I did have to modify mine slightly. I had to copy the EFI off the Windows drive and put it on main SSD. This was so automate (and the regular boot loader) would load the external Windows drive.
Success at last! Because my external SSD has an EFI boot I decided to keep the manual DSDT override, halt work on automate-eGPU and concentrate on disabling resources. These are my five:
PCI bus 14, device 0, function 0 - Standard SATA AHCI Controller
PCI slot 4 (PCI bus 21, device 5, function 0)
PCI bus 17, device 10, function 0
PCI bus 21, device 0, function 0
PCI bus 0, device 30, function 0
However, Win10 downloaded 1809 updates overnight so I could not avoid them being installed on restart this morning. The install went in after a few failed runs (probably due to the resources that are diabled causing confusion). Good news is the eGPU still works. This raises the question of if the eGPU can be made to work with a 'normal' full build of 1809.
This is great! Three separate instances of eGPU working under Bootcamp on the nMP. All very distinct setups as well.
I think that we can safely say it ‘works’ with somewhat minimal effort. Once Windows 10 is stable with eGPUs in general and automate-eGPU EFI has been updated for full compatibility with Catalina, I’ll rebuild my Windows drive onto an SSD, get Catalina installed and then write up a build. For now, I’m going to enjoy gaming on the RX 580 on a quieter and cooler machine than my 5.1 Mac Pro. 😁
I just joined the forum to say thank you! I game on a trashcan and ever since I got it have been reading about the possibility of using an egpu in bootcamp. Recently I did a google search and sorted by recent and found this page. I don't even have an external card or enclosure yet but just reading about your success gives me hope! So thanks for your hard work. Keep it up!
Pending: Add my system information and expected eGPU configuration to my signature to give context to my posts
So, I wanted to give 1903 (18362.418) a whirl and... bupkis. RX 580 is error 12’d or 43’d, no matter how many PCI bridges I disable. Unfortunately, since this is a completely fresh install on a new drive, I can’t rollback to a working build (short of reinstalling Windows).
@aj_scarcella That was my experience as well with Win10 1903. One thing I forgot to test was using clean Radeon drivers directly from AMD website rather than the modified drivers from bootcampdrivers.com. Error 43 is essentially a drivers compatibility issue between dGPU and eGPU. If we can get the external GPU working with screen output and acceleration, no drivers for the dGPU is no problem. Maybe try turning on Remote Desktop (in case no screen output) in Windows prior to DDU all graphics drivers then install latest Radeon drivers.