[Success] AMD RX6000 Series working in macOS

[oli.mathieu]

Apple first had support for RX 5000 in macOS 10.15.1 beta which was released in Oct. 11, 2019. I believe the 16-inch MBP was the first Apple hardware that had Rx 5000 GPU inside and that was released in Nov. 13, 2019.

thanks

AMD would probably prioritise supply to Apple, to keep in their good books.

Good to know. thanks

 

[panorama]

hey man, seems like we have similar setups, are you able to send me your EFI folder? cant boot... there must be something im doing wrong. im sutck in Failed to bootstrap path.

Or if anyone can check it out ill really appreciate it!

Hey guys solve it, apparently there are two kexts files that slow down the process big time, also with the error "diskX is write locked"

If someone else is in the same position you need to remove "BrcmPatchRAM3.kext" and "BrcmFirmware" Kexts and it will work perfectly. bluetooth working without those kext files.

Of course no acceleration, but at list working screen trough DP, HDMI and TB3

 

[Ploddles]

Hey guys solve it, apparently there are two kexts files that slow down the process big time, also with the error "diskX is write locked"

If someone else is in the same position you need to remove "BrcmPatchRAM3.kext" and "BrcmFirmware" Kexts and it will work perfectly. bluetooth working without those kext files.

Of course no acceleration, but at list working screen trough DP, HDMI and TB3

The kexts you use depend on the hardware you have installed. You can't just delete random kexts and expect everything to work. Some users may/will require one or both of those kexts if they have the hardware installed that need it/them.

 

[sefki21]

I've been running two GPUs - 6800 in slot 1, Vega 64 in slot 3 - for the last month and it's working fine. In macOS I use an SSDT to disable the 6800, and in Windows I use "Disable Driver" to disable the Vega 64.

I did briefly try running Windows with the Vega 64 enabled, but I started getting lower frame rates and jerky action in the game I was playing. Not 100% certain it was connected to enabling the Vega 64, but I disabled it again to be sure. I haven't connected that extra power cable for running two GPUs, which I guess I should if I plan to have them both enabled. I did wonder whether maybe the 6800 wasn't able to draw as much power with the Vega 64 enabled and that caused it to run slower, though I'm not sure if it works like that; I'd have expected a crash or blue screen if I had power issues, not lower performance.

I also run DaVinci Resolve and saw that Puget review and it was quite disappointing. However, as you mention, I took solace in the fact that they tested on Windows using OpenCL. Windows Resolve doesn't use AMD's Vulkan, and OpenCL is known to be much weaker than NVidia's CUDA.

I believe macOS' metal is regarded as a pretty capable and powerful compute API; potentially a rival to CUDA, albeit much newer. Therefore my hope is that Metal + AMD will be much more competitive compared to CUDA + NVidia than OpenCL + AMD is.

When the 6000 series GPUs are supported in macOS I plan to do a benchmark test, comparing Resolve in Windows using OpenCL vs Resolve in macOS using Metal. My hope is that I see noticeably better performance in macOS. I don't have an NVidia GPU to compare against, but if macOS Metal does outperform Windows OpenCL then that would be some indication that that Puget comparison benchmark isn't applicable to video editing on macOS.

Regardless of API, once fully supported in macOS I'm sure 6000 series GPU will outperform a Radeon VII.

Hi, i‘m using a X570 board with 6900XT in Slot 1 and 570 in Slot 3 until drivers *may* release, but disabling 6900XT in macOS always fails.

There is no difference at all with Device Properties way. With multiple SSDTs (also the one on Dortania’s Tut) and even disabling the whole device on slot level, did not bring a change with loading drivers for it, always gets loaded as gfx0. If disabled with SSDT the only change is, that the device names disappear in IOReg and get replaced with „PCI-Bridge“.

how did you manage it?

 

[sefki21]

Yeah, tried that already, verified the path also with Hackintool and gfxutil, but macOS still recognizes the card. Here my config:

and still recognized by macOS at that path with real values:

 

[StefanAM]

Yeah, tried that already, verified the path also with Hackintool and gfxutil, but macOS still recognizes the card. Here my config:

View attachment 509290


and still recognized by macOS at that path with real values:

View attachment 509292

Same here, with SSDT or Properties.

 

[sefki21]

it's normal show the display card info ,when you block slot 1.it's same to me but system work fine !

It breaks sleep for me, without the card installed everything is fine, but removing the card every time I boot macOS is not really great

 

[StefanAM]

It breaks sleep for me, without the card installed everything is fine, but removing the card every time I boot macOS is not really great

Same here.

 

[Higgie]

It breaks sleep for me, without the card installed everything is fine, but removing the card every time I boot macOS is not really great

Instead of removing the card, you can just remove power from the card. That's what I've had to do for now, and it works. The card isn't powered so it's not seen my macOS, and sleep should still work.

 

[TheBloke]

It breaks sleep for me, without the card installed everything is fine, but removing the card every time I boot macOS is not really great

Same here.

Broken sleep even with the SSDT is expected and normal on the 6000-series cards. I think I wrote about this some pages back.

To fix sleep with non-supported 6000-series cards on macOS requires two steps:

1. SSDT to disable the card;
2. USB mapping to disable the USB hub on the card - look for a USB hub with AMD's vendor ID (1002) and make sure it's not in your USB map. Instructions for USB mapping can be found on Dortania.

Issue 2 is new and unique to these 6000 series cards, given they have a USB-C output - or at least the reference/MBA cards do. Some AIB cards remove it, and it's possible that step 2 doesn't apply on those. But on reference cards it definitely does.

That USB-C out on the back of reference cards works as a full GPU output with the appropriate USB-C to DislayPort cable, but it is also a fully functioning USB-C port. You can literally plug a mouse or USB flash drive into it, and it works like any other USB port.

Unfortunately this also causes macOS sleep to break. I don't know if that's related to requiring the SSDT due to lack of driver support - ie whether the SSDT disabling the GPU device is also causing the USB hub to not initialise the info it needs to support sleep - or whether they are unrelated and USB mapping might still be required for 6000-series cards even when (if) full accelerated GPU drivers are available.

But it's definitely required right now if you want sleep to work.