Contribute
Register

[Success] Radeon RX 6800 XT - Big Sur

CaseySJ

Moderator
Joined
Nov 11, 2018
Messages
17,252
Motherboard
Gigabyte Z490 Vision D
CPU
i5-10400
Graphics
RX 580
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac Pro
Classic Mac
  1. Quadra
Mobile Phone
  1. iOS
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.
 
Joined
May 29, 2012
Messages
568
Motherboard
Gigabyte Z390 Gaming X
CPU
i9-9900K
Graphics
Vega 56
Mac
  1. iMac
Classic Mac
  1. LC
  2. Power Mac
  3. PowerBook
Mobile Phone
  1. iOS
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. :(
 
Joined
Oct 21, 2021
Messages
38
Motherboard
Apple MacBookPro16,1 - 1715.40.15.0.0 - OpenCore
CPU
i9-9980HK
Graphics
UHD 630 + Radeon Pro 5500M
Mac
  1. MacBook Air
  2. MacBook Pro
Mobile Phone
  1. iOS
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

Moderator
Joined
Nov 11, 2018
Messages
17,252
Motherboard
Gigabyte Z490 Vision D
CPU
i5-10400
Graphics
RX 580
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac Pro
Classic Mac
  1. Quadra
Mobile Phone
  1. iOS
@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

Moderator
Joined
May 15, 2016
Messages
6,566
Motherboard
GIGABYTE X470 Arous Gaming 7 WiFi
CPU
Ryzen R9 3900X
Graphics
RX 480
Mac
  1. iMac
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.

Thunderbolt PEG2.png

Take a look at this SSDT.
 

Attachments

  • SSDT-EGFX.aml
    149 bytes · Views: 14
Joined
May 29, 2012
Messages
568
Motherboard
Gigabyte Z390 Gaming X
CPU
i9-9900K
Graphics
Vega 56
Mac
  1. iMac
Classic Mac
  1. LC
  2. Power Mac
  3. PowerBook
Mobile Phone
  1. iOS
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

Moderator
Joined
Nov 11, 2018
Messages
17,252
Motherboard
Gigabyte Z490 Vision D
CPU
i5-10400
Graphics
RX 580
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac Pro
Classic Mac
  1. Quadra
Mobile Phone
  1. iOS
@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?
 
Joined
May 29, 2012
Messages
568
Motherboard
Gigabyte Z390 Gaming X
CPU
i9-9900K
Graphics
Vega 56
Mac
  1. iMac
Classic Mac
  1. LC
  2. Power Mac
  3. PowerBook
Mobile Phone
  1. iOS
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.
 
Joined
Oct 21, 2021
Messages
38
Motherboard
Apple MacBookPro16,1 - 1715.40.15.0.0 - OpenCore
CPU
i9-9980HK
Graphics
UHD 630 + Radeon Pro 5500M
Mac
  1. MacBook Air
  2. MacBook Pro
Mobile Phone
  1. iOS
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.
 

Attachments

  • MacBook Pro.ioreg
    39.9 MB · Views: 11
  • config.plist
    12.4 KB · Views: 7
Last edited:
Top