[Success] AMD RX6000 Series working in macOS

[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.

 

[CaseySJ]

@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.

In that case does latest version of WhateverGreen enable the RX 6900XT to be recognized by macOS?

 

[tedyun]

In that case does latest version of WhateverGreen enable the RX 6900XT to be recognized by macOS?

@CaseySJ : We will have to see. I doubt it. In order for the spoof to work, there are two paths that need to be specified by the SSDT-BRG0.aml, then by the config.plist. I think he fixed the device-id issue a few days ago, but it still doesn't work with the eGPU. Let's see if he has any luck with Gigamaxx's SSDT.

 

[WrathOfThePast]

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

@CaseySJ, @tedyun did a good job summing everything up, but to clarify: I've been able to add the "model" & when I had the typo: "device_id" in DeviceProperties, it successfully added the field: "device_id." However, when the typo was corrected, it failed to overwrite the device-id.

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.

The display plugged into the eGPU receives a signal for a brief moment during boot... Interestingly enough, if I shorten the device path to PEG2, UPSB, DSB1, or USP0 (the path for eGFX prior to the 3 pci-bridges), it is able overwrite the respective device-id... sounds like the issue has to do with the three pci-bridges:

Let's see if he has any luck with Gigamaxx's SSDT.

I tried @Gigamaxx's SSDT, but to no avail. I installed the debug version of WEG & Lilu added the debug boot-args for both to try to figure it out... can't find any logs though.

Under the 3rd pci-bridge is eGFX & "pci1002,ab28@0,1." The latter is HDMI audio for the eGPU and it's loaded... the 6800, 6800 XT, 6900 XT all share the same device-id & subdevice-id for HDMI audio hence why that's working. Is it possible the SSDT is failing to rename that 3rd pci-bridge (hence the failure to overwrite the device-id) because it's shared between loaded HDMI audio component and eGFX?

In that case does latest version of WhateverGreen enable the RX 6900XT to be recognized by macOS?

I've been on the latest version (v1.5.4) from the beginning. However, at one point, I did try v1.5.2 as v1.5.3 added:

• Added no-gfx-spoof to avoid forcing device-id values from PCI I/O.

Nothing else in the release notes for v1.5.3 & v1.5.4 applied to me and v1.5.2 "added device-id spoofing support for AMD graphics." Should I go back to troubleshooting with v1.5.2 (keeping the current version of Lilu of course)?

Perhaps an uploaded IOReg could shed more light on it?

Here's my IOReg with your SSDT as well as my config.plist... I'm currently on Lilu v1.5.6 & WEG v1.5.4.

 

[tedyun]

@CaseySJ, @tedyun did a good job summing everything up, but to clarify: I've been able to add the "model" & when I had the typo: "device_id" in DeviceProperties, it successfully added it. However, when the typo was corrected, it failed to overwrite the device-id.

The display plugged into the eGPU receives a signal for a brief moment during boot... Interestingly enough, if I shorten the device path to PEG2, UPSB, DSB1, or USP0 (the path for eGFX prior to the 3 pci-bridges), it is able overwrite the respective device-id... sounds like the issue has to do with the three pci-bridges:

I tried @Gigamaxx's SSDT, but to no avail. I installed the debug version of WEG & Lilu added the debug boot-args for both to try to figure it out... can't find any logs though.

Under the 3rd pci-bridge is eGFX & "pci1002,ab28@0,1." The latter is HDMI audio for the eGPU and it's loaded... the 6800, 6800 XT, 6900 XT all share the same device-id & subdevice-id for HDMI audio hence why that's working. Is it possible the SSDT is failing to rename that 3rd pci-bridge (hence the failure to overwrite the device-id) because it's shared between loaded HDMI audio component and eGFX?

I've been on the latest version (v1.5.4) from the beginning. However, at one point, I did try v1.5.2 as v1.5.3 added:

• Added no-gfx-spoof to avoid forcing device-id values from PCI I/O.

Nothing else in the release notes for v1.5.3 & v1.5.4 applied to me and v1.5.2 "added device-id spoofing support for AMD graphics." Should I go back to troubleshooting with v1.5.2 (keeping the current version of Lilu of course)?

Here's my IOReg with your SSDT as well as my config.plist... I'm currently on Lilu v1.5.6 & WEG v1.5.4.

A valiant effort for sure, @WrathOfThePast ! I hope you're rewarded for your tenacity and make a breakthrough.

Just a correction here:

when I had the typo: "device_id" in DeviceProperties, it successfully added it. However, when the typo was corrected, it failed to overwrite the device-id.

"device_id" is essentially meaningless. The DeviceProperties told it to add it, but it is doesn't have any relevant value in telling the macOS anything about the card. macOS is looking for the "device-id" value. The ability to spoof comes with tricking macOS to recognize the "device-id" as a 73bf, when the card is telling it 73af.

 

[WrathOfThePast]

A valiant effort for sure, @WrathOfThePast ! I hope you're rewarded for your tenacity and make a breakthrough.

Just a correction here:

when I had the typo: "device_id" in DeviceProperties, it successfully added it. However, when the typo was corrected, it failed to overwrite the device-id.

"device_id" is essentially meaningless. The DeviceProperties told it to add it, but it is doesn't have any relevant value in telling the macOS anything about the card. macOS is looking for the "device-id" value. The ability to spoof comes with tricking macOS to recognize the "device-id" as a 73bf, when the card is telling it 73af.

@tedyun, I know. CaseySJ asked if I could add a fake device property, so I was merely answering his question. You're right I should've made that more clear... I edited it to make it more clear. Thanks.