[Success] AMD RX6000 Series working in macOS

[tedyun]

It seems you’ve installed your NAVI GPU into a Thunderbolt eGPU. Spoofing the device-id is most likely failing for that reason.

Hi @CaseySJ

Would it be possible to alter the SSDT-BRG0.aml in order to specify the ACPI path to the eGPU?

This is the current path to his eGPU:

/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG2@1,2/IOPP/UPSB@0/IOPP/DSB1@1/IOPP/UPS0@0/IOPP/pci-bridge@1/IOPP/pci-bridge@0/IOPP/pci-bridge@0/IOPP/display@0

Thanks for your help!

Ted

 

[CaseySJ]

Hi @CaseySJ

Would it be possible to alter the SSDT-BRG0.aml in order to specify the ACPI path to the eGPU?

This is the current path to his eGPU:

/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/PEG2@1,2/IOPP/UPSB@0/IOPP/DSB1@1/IOPP/UPS0@0/IOPP/pci-bridge@1/IOPP/pci-bridge@0/IOPP/pci-bridge@0/IOPP/display@0

Thanks for your help!

Ted

We cannot and should not impose fixed device properties on a hot plug port!

We should install the RX 6900XT in one of the PCIe x16 slots on motherboard.

 

[tedyun]

We should install the RX 6900XT in one of the PCIe x16 slots on motherboard.

He can't do that because he is trying to use the eGPU on his Macbook Pro.

 

[CaseySJ]

He can't do that because he is trying to use the eGPU on his Macbook Pro.

At this particular time I think the options are limited for eGPU users:

• Replace the RX 6900XT with one whose device-id is already 0x73BF.
• Flash a new VBIOS into the existing RX 6900XT that sets device-id to 0x73BF.
  • This is tricky and could brick the card.
  • But some have done this by extracting the VBIOS from a 6900XT with device-id 0x73BF and flashing that one as-is.
• Consider a 6800XT instead of 6900XT.

 

[tedyun]

At this particular time I think the options are limited for eGPU users:

• Replace the RX 6900XT with one whose device-id is already 0x73BF.
• Flash a new VBIOS into the existing RX 6900XT that sets device-id to 0x73BF.
  • This is tricky and could brick the card.
  • But some have done this by extracting the VBIOS from a 6900XT with device-id 0x73BF and flashing that one as-is.
• Consider a 6800XT instead of 6900XT.

@WrathOfThePast , @Sebseb82, it doesn't sound like an eGPU can be used with the spoof.

 

[CaseySJ]

@WrathOfThePast , @Sebseb82, it doesn't sound like an eGPU can be used with the spoof.

Another suggestion is to consider browsing and searching the https://egpu.io website. @joevt may also have some advice.

 

[WrathOfThePast]

Another suggestion is to consider browsing and searching the https://egpu.io website. @joevt may also have some advice.

@CaseySJ, @tedyun egpu.io referred me here... they were working on a kext to add the device-id for Navi21 XTXH to the existing the drivers (in contrast to spoofing), but they never finished it and gave up. However, I got some hope at the moment because after a ton of research since my last post, I figured out some of the issues:

1. All dGPUs are "GFX0" no matter how many you have (ie "GFX1" is invalid).
2. However, eGPUs are not "GFX0." They are "EGFX," so that was one of my issues with my SSDT.
3. All Navi 21 (6800, 6800 XT, 6900 XTX/XTXH) GPUs have the same HDMI audio device-id, subdevice-id, & kext. This means that nothing is needed to make HDMI audio work and likely works without spoofing the device-id for GFX0 (in my case EGFX).
4. In terms of adding "model" to DeviceProperties, one should enter is as hexadecimal (with type: data) as that matches how my 5500M appears in the I/O Registry. I doubt this makes any functional difference, but it is a parity improvement.
5. I have a boot logo drawing issue which the WEG FAQs address how to fix (supposedly only a "recommended" cosmetic issue to fix, but it's an issue nonetheless).

My questions:
1. WEG states agdpmod= vit9696 & pikera boot-args are "implicit default for dGPUs." Should I not be using agdpmod=pikera boot-arg or should I also be using agdpmod=vit9696?
2. Do I complicate things by updating to Monterey? Theoretically, the kext mac_editor made on egpu.io may work on Monterey as it was left off as a compatibility issue with Big Sur that isn't present in Monterey (not saying that there aren't other issues though).

 

[CaseySJ]

@CaseySJ, @tedyun egpu.io referred me here... they were working on a kext to add the device-id for Navi21 XTXH to the existing the drivers (in contrast to spoofing), but they never finished it and gave up. However, I got some hope at the moment because after a ton of research since my last post, I figured out some of the issues:

1. All dGPUs are "GFX0" no matter how many you have (ie "GFX1" is invalid).
2. However, eGPUs are not "GFX0." They are "EGFX," so that was one of my issues with my SSDT.
3. All Navi 21 (6800, 6800 XT, 6900 XTX/XTXH) GPUs have the same HDMI audio device-id, subdevice-id, & kext. This means that nothing is needed to make HDMI audio work and likely works without spoofing the device-id for GFX0 (in my case EGFX).
4. In terms of adding "model" to DeviceProperties, one should enter is as hexadecimal (with type: data) as that matches how my 5500M appears in the I/O Registry. I doubt this makes any functional difference, but it is a parity improvement.
5. I have a boot logo drawing issue which the WEG FAQs address how to fix (supposedly only a "recommended" cosmetic issue to fix, but it's an issue nonetheless).

My questions:
1. WEG states agdpmod= vit9696 & pikera boot-args are "implicit default for dGPUs." Should I not be using agdpmod=pikera boot-arg or should I also be using agdpmod=vit9696?

So far all AMD RX 6000 series GPUs have required boot argument agdpmod=pikera. (And only that one.)

2. Do I complicate things by updating to Monterey? Theoretically, the kext mac_editor made on egpu.io may work on Monterey as it was left off as a compatibility issue with Big Sur that isn't present in Monterey (not saying that there aren't other issues though).

Yes it's probably best to attempt the experiments in Big Sur first because we already know that some drivers such as SmallTreeIntel82576 are having problems in Monterey, as is the Intel I-225V 2.5GbE port. Both of them used to work in Big Sur.

Have you been able to inject even some random or made-up device properties to EGFX via an SSDT or OpenCore DeviceProperty?

My feeling (and I say feeling because I haven't actually done this) is that at early boot stage when SSDTs and Device Properties would be injected, peripherals attached to the Thunderbolt bus may not exist in IOReg. Which means, of course, that the PciPath we're trying to address won't yet exist.

Hence my question as to whether you've been able to inject even a made-up device property to EFGX?

 

[Gigamaxx]

So far all AMD RX 6000 series GPUs have required boot argument agdpmod=pikera. (And only that one.)


Yes it's probably best to attempt the experiments in Big Sur first because we already know that some drivers such as SmallTreeIntel82576 are having problems in Monterey, as is the Intel I-225V 2.5GbE port. Both of them used to work in Big Sur.

Have you been able to inject even some random or made-up device properties to EGFX via an SSDT or OpenCore DeviceProperty?

My feeling (and I say feeling because I haven't actually done this) is that at early boot stage when SSDTs and Device Properties would be injected, peripherals attached to the Thunderbolt bus may not exist in IOReg. Which means, of course, that the PciPath we're trying to address won't yet exist.

Hence my question as to whether you've been able to inject even a made-up device property to EFGX?

Here is the IOReg screenshot. Perhaps an uploaded IOReg could shed more light on it? PEG0, PEG1? It would be
helpful. The 2 ID's means the SSDT is not taking allowing WEG to get past the real ID.



Take a look at this SSDT.

 

[tedyun]

Here is the IOReg screenshot. Perhaps an uploaded IOReg could shed more light on it? PEG0, PEG1? It would be
helpful. The 2 ID's means the SSDT is not taking allowing WEG to get past the real ID.

View attachment 532185

Take a look at this SSDT.

@WrathOfThePast found the source of the two "device-id" -- in the config.plist, he had accidentally specified "device_id" instead of "device-id". I had done the same thing. He has since corrected it and it reports a single device-id now.