[Success] AMD RX6000 Series working in macOS

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

 

[CaseySJ]

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

I’ll take a look soon at the IOReg you posted, but does it show “device-id” equal to 0x73AF or Px73BF?

 

[WrathOfThePast]

I’ll take a look soon at the IOReg you posted, but does it show “device-id” equal to 0x73AF or Px73BF?

@CaseySJ, device-id = <af 73 00 00> which translates to 0x73af.

 

[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 the field: "device_id." 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.

It says the IOReg file is corrupted....

 

[Gigamaxx]

It says the IOReg file is corrupted....

same here

 

[sashamed]

I need a little help. Since I start using PowerColor RX6900XT, everything works fine, but FCPX became very unstable. Any idea how to fix this? Maybe I need to put some acpi file in OC acpi folder?