MP All Models AMD Radeon RX 6800 XT / 6900 XT for macOS?

[startergo]

I suspect this is a case of AMD doesn't offer a driver for the card for macOS, therefore it's "not supported" by AMD.

Yes, but the problem is not with the driver, but with the interaction with the BIOS. It is a broken UEFI code/standard in the card vbios.

 

[mattspace]

Yes, but the problem is not with the driver, but with the interaction with the BIOS. It is a broken UEFI code/standard in the card vbios.

Sure, but if it doesn't effect Windows, the level 1 techs aren't going to have a script for how to direct it - hence "we don't make the software that drives it, therefore we don't support it".

 

[startergo]

Sure, but if it doesn't effect Windows

Right, but Mac Pro can boot Windows or mac OS not necessarily mac OS only, so that argument is hanging. The correct response would be RDNA2 does not support Mac Pro.

 

[Syncretic]

Yes, but the problem is not with the driver, but with the interaction with the BIOS. It is a broken UEFI code/standard in the card vbios.

I just noticed something, and I don't know if it makes me feel better or worse about AMD.

In the TianoCore sample code, we find:

EFI_STATUS
EFIAPI
InitializeSetup (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS  Status;
  VOID        *Registration;

  //
  // Locate required Hii relative protocols
  //
  Status = gBS->LocateProtocol (
                  &gEfiHiiDatabaseProtocolGuid,
                  NULL,
                  (VOID **)&mHiiDatabase
                  );
  ASSERT_EFI_ERROR (Status);

  Status = gBS->LocateProtocol (
                  &gEfiHiiConfigRoutingProtocolGuid,
                  NULL,
                  (VOID **)&mHiiConfigRouting
                  );
  ASSERT_EFI_ERROR (Status);
// {snip}

If debugging is disabled (as it would be in production code), the "error handling" is defined as #define ASSERT_EFI_ERROR(StatusParameter), meaning those ASSERTs do nothing.

A bit later, we have numerous instances similar to:

      Status    = mHiiConfigRouting->BlockToConfig (
                                       mHiiConfigRouting,
                                       ConfigRequest,
                                       SourceBuf,
                                       Storage->Size,
                                       ConfigResp,
                                       &Progress
                                       );

and

Status         = mHiiDatabase->ExportPackageLists (mHiiDatabase, Handle, &BufferSize, HiiPackageList);

So, with debugging disabled, the reference TianoCore code locates two HII protocols without checking for error returns, then later blindly uses those protocols (dereferences the returned pointers, which might be NULL (and are NULL on the MP5,1)), again without any error checking.

If AMD modeled their UEFI code on the TianoCore code, it's easy to see how this could have slipped into production; if they only tested their cards on late-model UEFI systems, there's no reason an error should have ever occurred, so it's easy to see how it slipped past QA. Still, it's damn sloppy programming - if there's even a remote chance of a pointer being NULL, it's crazy not to test it before using it (or, better yet, when its value is initially assigned). However, since AMD apparently "does not support Mac OS," I guess it's fine.

 

[startergo]

#define ASSERT_EFI_ERROR(StatusParameter)

Where is this snippet referenced? is it here only?

MdePkg/DebugLib.h: add ASSERT_RETURN_ERROR() · tianocore/edk2@08bcaf2

ASSERT_EFI_ERROR() cannot be used in BASE type modules because - the replacement text calls EFI_ERROR(), - EFI_ERROR() is defined in "MdePkg/Include/Uefi/UefiBaseType.h", - the inclusion ...

github.com

 

[Syncretic]

Where is this snippet referenced? is it here only?

MdePkg/DebugLib.h: add ASSERT_RETURN_ERROR() · tianocore/edk2@08bcaf2

ASSERT_EFI_ERROR() cannot be used in BASE type modules because - the replacement text calls EFI_ERROR(), - EFI_ERROR() is defined in "MdePkg/Include/Uefi/UefiBaseType.h", - the inclusion ...

github.com

The version in master still uses ASSERT_EFI_ERROR:

/** @file
  Provides services to print debug and assert messages to a debug output device.
  The Debug library supports debug print and asserts based on a combination of macros and code.
  The debug library can be turned on and off so that the debug code does not increase the size of an image.
  Note that a reserved macro named MDEPKG_NDEBUG is introduced for the intention
  of size reduction when compiler optimization is disabled. If MDEPKG_NDEBUG is
  defined, then debug and assert related macros wrapped by it are the NULL implementations.

// ... {snip} ...

/**
  Macro that calls DebugAssert() if an EFI_STATUS evaluates to an error code.
  If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
  bit of PcdDebugProperyMask is set, then this macro evaluates the EFI_STATUS
  value specified by StatusParameter.  If StatusParameter is an error code,
  then DebugAssert() is called passing in the source filename, source line
  number, and StatusParameter.
  @param  StatusParameter  EFI_STATUS value to evaluate.
**/
#if !defined (MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter)                                              \
    do {                                                                                 \
      if (DebugAssertEnabled ()) {                                                       \
        if (EFI_ERROR (StatusParameter)) {                                               \
          DEBUG ((DEBUG_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", StatusParameter));  \
          _ASSERT (!EFI_ERROR (StatusParameter));                                        \
        }                                                                                \
      }                                                                                  \
    } while (FALSE)
#else
#define ASSERT_EFI_ERROR(StatusParameter)
#endif

 

[startergo]

So, with debugging disabled, the reference TianoCore code locates two HII protocols without checking for error returns, then later blindly uses those protocols

So, if this is error in TianoCore why don't you create a pull request at the github repository?

 

[Dayo]

So, if this is error in TianoCore why don't you create a pull request at the github repository?

A PR will probably be pointless as it is not so much an error (bug) as more of a possible design flaw, if you want to call it that way, since such "ASSERT Macro" error gating is how TianoCore is basically written from the ground up. One would pretty much have to PR the whole codebase to change this ... with a high chance of rejection.

When I started doing static analysis on RefindPlus, I put the REL build in and it was spitting out errors in the UDK code that I tried to cover with what I called "Assert Proxies".

Basically adding error gating code that would work on the REL build:

Add Assert Proxies · dakanji/RefindPlusUDK@db70723

RefindPlus UEFI Development Kit. Contribute to dakanji/RefindPlusUDK development by creating an account on GitHub.

github.com

Add Assert Proxies · dakanji/RefindPlusUDK@5edd4d2

RefindPlus UEFI Development Kit. Contribute to dakanji/RefindPlusUDK development by creating an account on GitHub.

github.com

Add Assert Proxies · dakanji/RefindPlusUDK@986bb66

RefindPlus UEFI Development Kit. Contribute to dakanji/RefindPlusUDK development by creating an account on GitHub.

github.com

Account for Release Builds with ASSERTS · dakanji/RefindPlusUDK@ae31234

RefindPlus UEFI Development Kit. Contribute to dakanji/RefindPlusUDK development by creating an account on GitHub.

github.com

I later gave up and only put the debug build through static analysis.

Basically, the EDK design appears to be that if you get a problem with your production build, you need to run the Debug build through the scenario, see where that hangs and figure things out from there.

Later on, I found that that you can set your production build to call the ASSERT macros when compiling. I suppose AMD, similar to a beffuddled amateur such as me, didn't take the extra steps needed to do this. From what i can see, you need to know this can be done, decide you want to, and specifically go out of your way to do this. Otherwise, the basic REL/DBG relationship apparently applies.

EDIT:
One thing to bear in mind though is that if the flow misses an Assert, such as in the REL build, you get an uncontrolled crash and if it hits the Assert in the DBG build, you get a forced reset or go into a CPU deadloop depending on the compilation settings. Either way, the flow stops and the item does not work. Just controlled when the Assert macro test fails.

If the item could still work regardless of the Assert macro failing, then an Assert macro should not be there and some other conditional handling block is needed instead. This might be a candidate for a PR if this is the case here.

 

[mattspace]

Right, but Mac Pro can boot Windows or mac OS not necessarily mac OS only, so that argument is hanging. The correct response would be RDNA2 does not support Mac Pro.

Does the issue you're dealing with still happen when the machine is booted in Windows?

 

[joevt]

One thing to bear in mind though is that if the flow misses an Assert, such as in the REL build, you get an uncontrolled crash and if it hits the Assert in the DBG build, you get a forced reset or go into a CPU deadloop depending on the compilation settings. Either way, the flow stops and the item does not work. Just controlled when the Assert macro test fails.

Speaking of ASSERTs, debug builds, and UDK, I ran into a problem with OpenShell on my MacPro3,1 and iMac14,2 recently.
https://github.com/acidanthera/bugtracker/issues/2005

When there are more than 25 file systems, OpenShell stops at this line containing an ASSERT_EFI_ERROR:
https://github.com/tianocore/edk2/b...fiShellCommandLib/UefiShellCommandLib.c#L1359

The assert outputs a debug message that includes the source file name and line number where it occurred which is how I found the source code line.

OpenCore recently added support for PCIe serial port cards, so I can output debug messages to serial port (I have a PCIe serial port card in a Thunderbolt enclosure connected to the iMac14,2).
https://github.com/acidanthera/bugtracker/issues/1954

I suppose there's a setting to get debug messages to the graphical EFI console (if you have a working graphical EFI console).

 

[startergo]

Does the issue you're dealing with still happen when the machine is booted in Windows?

The issue affects the booting process long before an operating system is selected.

 

[NicoFR75]

By design, the Mac Pro EFI BootROM uses UGA (an older standard) for screen output. Mac-compatible cards provide UGA, which lets you see the native boot picker and the early boot screens (before MacOS loads). Without a UGA-compatible card (i.e. with non-Mac/PC cards), you'll see a black screen until something loads a driver that can speak to your video card - that's typically either OpenCore or MacOS itself. OpenCore loads early enough that the native screens aren't really necessary. As I understand it (I've never looked at an MVC card), MVC patches their cards to include UGA support, so you can use the native boot picker and see the boot screens immediately, without the need for OpenCore. (And, in the case of the RX6x00 cards, they've presumably fixed the same AMD bug that my patch fixes.)



Unfortunately, yes. As @tsialex correctly points out, you can't boot a cMP with an unpatched RX6x00 card in it; the card's initialization code contains a bug that prevents booting (fixing that is the whole point of my patch!). So, if you're using software flashing, you'll need to do that on a non-Mac PC.

To simplify things, I've attached a Windows version of the FixRX6x00 patcher program. It's still a command-line program (no GUI), same instructions as the MacOS version in my previous post. At least this way, there's less shuffling back and forth between systems.



Your Python script has a problem. It complains about the EFI ROM not being the last image, but that's not a requirement for EFI option ROMs. In this case, the x86_64 EFI code appears before the ARM64 EFI code - but in the output from your script, the ARM64 code gets removed. Also, while I don't have an RX6900XT to test with, I can state that GOP is most definitely provided by the card's original ROM.



Correct. As I said in my original post, @caingraywood was using a hardware flasher (I think he said it was an RT809F). I don't know his methodology - he may have been flashing in situ, or he may have been physically replacing the chips. In any case, he wasn't using software flashing. Since a cMP can't even POST with an unpatched RX6x00 card, it's necessary to flash it using either a PC (Windows/Linux) or a hardware flasher (or, I suppose, a MP7,1?).

To help simplify things, I pulled all of the RX6600/6600XT/6800/6800XT/6900XT ROMs from TechPowerup, patched them, and have attached them to this post. However, be advised that patching the ROM that came with your particular card will almost always be the better choice. Use the attached ROM images at your own risk. If you choose to use one of the attached ROM images, verify that the make/model and version number matches your card.

Hello,

I've just applied it to a brand new "Sapphire RX6600XT Nitro+" and it worked.
I can boot my MacPro on Monterey 12.3.1 and on Windows 10.

But there's a still a little thing I need to fix.

When booting on macOS, the bar shows just like before, progresses to almost 50% and then the screen turns black with white vertical bars. Just after that the screen turn completely black and I have to unplug/plug the DisplayPort connector to get the screen back to life.

My screen is an Apple Cinema Display 30" and I'm using the Apple Mini-DisplayPort to DVI-D adaptor.

Anyone knows if it's something that can be fixed with opencore (currently using 0.7.9) ?

 

[startergo]

Anyone knows if it's something that can be fixed with opencore (currently using 0.7.9) ?

Are you using agdpmod=pikera boot argument?

 

[prefuse07]

Are you using agdpmod=pikera boot argument?

FYI, to anyone wondering, I am NOT using agdpmod=pikera on my RX-6800XT , in my config i'm using the following boot args only:

-no_compat_check wegtree=1 unfairgva=1 shikigva=80

That's it, everything works 100% fine, no stutters, no black screens, no issues on both macOS 11.6.5 and Windows with OpenCore 0.8.0

 

[ssj92]

Wow this is awesome, didn't realize the 6xxx series was made working in cMP.

May sell my 5700 XT and get a RX 6800

 

[LeonPro]

Reposting the question here in case someone has gone through the same experience:

I installed the Gigabyte RX 6900 XT Gaming OC card in slots 3-4. Installed it on top of my Vega II at slots 1-2. Utilised the Belkin AUX power cables for the Mac Pro at 8-pin x 3. Install went well.

My concern is that RX 6900 XT doesn't have USB-C/Thunderbolt connections so both of my monitors are connected to the Vega II. With that being the case, how is the 6900 XT being utilised by the OS Monterey? Does it automatically switch to the best GPU for the OS-level tasks? Or is it just sitting there useless unless a specific app can be directed to use which GPU?

I tried connecting an HDMI cable from the GPU to one of my monitors, but I just see occasional flickering for some reason. I ordered a USB-C to DisplayPort bi-directional cable from Amazon and will see if this addresses this issue.

I realise Bootcamp is an issue with third-party GPU because you have to uninstall the MPX GPU and its drivers. Both GPU is not supported. Any work-around for this and still have both under Bootcamp?

Thanks to those who navigated through this hurdle.

 

[ssj92]

FYI, to anyone wondering, I am NOT using agdpmod=pikera on my RX-6800XT , in my config i'm using the following boot args only:

-no_compat_check wegtree=1 unfairgva=1 shikigva=80

That's it, everything works 100% fine, no stutters, no black screens, no issues on both macOS 11.6.5 and Windows with OpenCore 0.8.0

Interesting, I have a 5700 XT and I am getting stutters when playing videos. So I am assuming it's one of the boot args then? This is mine:

-lilubetaall -wegbeta agdpmod=pikera enable-gva-support shikigva=80 unfairgva=1 mbasd=1 -wegtree -no_compat_check no32exec=0

 

[prefuse07]

Interesting, I have a 5700 XT and I am getting stutters when playing videos. So I am assuming it's one of the boot args then? This is mine:

-lilubetaall -wegbeta agdpmod=pikera enable-gva-support shikigva=80 unfairgva=1 mbasd=1 -wegtree -no_compat_check no32exec=0

It looks like you're using Martin's package, am I correct?

 

[ssj92]

It looks like you're using Martin's package, am I correct?

Yes that's correct

 

[prefuse07]

Yes that's correct

I used to use it when I was first learning about OC myself, but since his package is designed to work on many machine, it does contain a lot of extras that your machine may not necessarily need, thus leading to the issues you are facing.

Perhaps you should ask him in the activate AMD acceleration thread? Since you are using his package.

 

[NicoFR75]

Are you using agdpmod=pikera boot argument?

Initially no, I tried :

- agdpmod=pikera
- -no_compat_check wegtree=1 unfairgva=1 shikigva=80
- -no_compat_check wegtree=1 unfairgva=1 shikigva=80 agdpmod=pikera

but it doesn't change anything

 

[ssj92]

Hello,

I've just applied it to a brand new "Sapphire RX6600XT Nitro+" and it worked.
I can boot my MacPro on Monterey 12.3.1 and on Windows 10.

But there's a still a little thing I need to fix.

When booting on macOS, the bar shows just like before, progresses to almost 50% and then the screen turns black with white vertical bars. Just after that the screen turn completely black and I have to unplug/plug the DisplayPort connector to get the screen back to life.

My screen is an Apple Cinema Display 30" and I'm using the Apple Mini-DisplayPort to DVI-D adaptor.

Anyone knows if it's something that can be fixed with opencore (currently using 0.7.9) ?

I have a similar issue. My miniDP to DVI adapter is running firmware 1.02 and I believe 1.03 had made this issue better.

For me it's a 60/40 , most of the time the display comes on after loading screen, but sometimes it stays black screen. When that happens I unplug the usb powering the mDP to DVI adapter and plug back in. That always fixes the issue.

I think it's more of an adapter issue. I tried a non Apple mDP to DVI adapter and that one was way worse.

 

[NicoFR75]

I have a similar issue. My miniDP to DVI adapter is running firmware 1.02 and I believe 1.03 had made this issue better.

For me it's a 60/40 , most of the time the display comes on after loading screen, but sometimes it stays black screen. When that happens I unplug the usb powering the mDP to DVI adapter and plug back in. That always fixes the issue.

I think it's more of an adapter issue. I tried a non Apple mDP to DVI adapter and that one was way worse.

You're probably right, I've just tried with another display connected on HDMI and it's working well.
Also I've noticed that if I unplug/plug the USB connector of the adapter it's brings the display to life just like when I unplug/plug the DP connector.

My adapter is quite old and I almost never used it until today, it's still on 1.02 firmware.
I'll look if I can upgrade it to 1.03.

 

[ssj92]

You're probably right, I've just tried with another display connected on HDMI and it's working well.
Also I've noticed that if I unplug/plug the USB connector of the adapter it's brings the display to life just like when I unplug/plug the DP connector.

My adapter is quite old and I almost never used it until today, it's still on 1.02 firmware.
I'll look if I can upgrade it to 1.03.

Let me know if you find out if we can get the 1.03 firmware and flash it to ours. All I found was a program back in the day from Apple where they replace it with a 1.03 model.

 

[NicoFR75]

Let me know if you find out if we can get the 1.03 firmware and flash it to ours. All I found was a program back in the day from Apple where they replace it with a 1.03 model.

Do somebody already try this adapter ?