Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP All Models AMD Radeon RX 6800 XT / 6900 XT for macOS?
- Thread starter Xenobius
- Start date
- Sort by reaction score
That card is from almost 5 years ago. 6700 XT should have gotten drivers a long time ago.
Exactly, and maybe 580X is not even manufactured anymore.
I was thinking about the savings, the price diffrence between 6600XT and 6700XT. Apple might not have brought drivers at all for 6600XT if there were not some kind of need for them. This card would be the new cheapest base model offering for Mac Pro.
Of course it could have been 5700XT too, so it was just a hunch or my best guess.
I was thinking about the savings, the price diffrence between 6600XT and 6700XT. Apple might not have brought drivers at all for 6600XT if there were not some kind of need for them. This card would be the new cheapest base model offering for Mac Pro.
Of course it could have been 5700XT too, so it was just a hunch or my best guess.
What's weird is how the 6600 XT was released just recently and Mac OS gets support for it but the 6700 XT came out back in March and Apple's still not doing anything about it.
Hi everyone,
Do you still have crashes with the 6900XT ?
I also have to deal with this problem and it makes me angry...1800 € for that issue !
Are there solutions ?
I'm about to install Monterey but i'm afraid that it would be worst...!
Do you still have crashes with the 6900XT ?
I also have to deal with this problem and it makes me angry...1800 € for that issue !
Are there solutions ?
I'm about to install Monterey but i'm afraid that it would be worst...!
I'm curious for anyone that's running a 6900 XT - how are your idle temps? I used https://github.com/aluveitie/RadeonSensor/releases to be able to read the temps on my reference 6900 XT to see how its temps are, and I noticed that it idles with the fans off at 62 degrees Celsius. I am running a hackintosh, but I was curious what real Mac Pro users are seeing? If I run something with a high GPU load, it will spin the fans up, cool it back down to 55 degrees, and then happily let the temps climb back to 62. Are you all seeing similar results? I wish there was a way to change the fan curve in macOS like you can with windows...
I also run my 6900 XT in slot 4 to keep it cooler and I use Lego for the sag LOL - , but I noticed the PCI lane allocation was not looking right. I think the Mac Pro motherboard runs better with GPUs in slots 1 and 3,
I saw that Sonnet released their version of the 6900, and they're claiming it supports the Ultrafine 5k. They do not specifically say if the card can drive it at 5k.
The Sonnet card looks like it's probably just a reference design, so guessing there isn't anything special. But what's the current status of the 6900 at the Ultrafine 5k? Did something change where now it runs at full res over USB-C?
The Sonnet card looks like it's probably just a reference design, so guessing there isn't anything special. But what's the current status of the 6900 at the Ultrafine 5k? Did something change where now it runs at full res over USB-C?
Nice! That is interesting... it looks like a stock 6900 XT GPU. Says it also supports Windows AND it is in stock which is quite amazing.
Usually reference cards say they pull 300W, this card says it pulls 360W even though the clocks are listed as being the same as reference.
FYI on which slots to use for GPUs, they should always be installed in slot 1 and/or 3.
softron.zendesk.com
So in very short:
HOW TO: Install PCIe cards in your 2019 Mac Pro
The 2019 Mac Pro allows to connect PCIe cards. Apple gives some recommendations on how to install and configure them. But below are some more recommendations. How to open the "Expansion Slot...
softron.zendesk.com
Are there any recommended slots?
The first things to verify are:- Which generation of the PCI protocol is your card using? Is it a PCIe gen1, PCIe gen2, or PCIe gen3?
- How many lanes does it use? Is it 16, 8 or 4 lanes (or less)
- If it's a 4 lane card, is it compatible with 8 or 16 lanes slots?
- If it's a 8 lane card, is it compatible with 16 lanes slots?
- Graphics cards should always be connected in slot 1 or 3.
- Other 16-lanes cards (such as the Afterburner), can be connected to the remaining 16-lanes slots (1, 3, 4 or 5). But if you have only one graphics card in slot 1, we recommend using slot 3. Indeed this slot won't count in the pool allocation, and thus will leave you more bandwidth for the remaining slots.
- 8 lanes and 4 lanes cards, prefer to use slots 6 or 7. Most AJA, Blackmagic-Design and M|Family cards should work fine in these slots. But most of these cards are also compatible with 16 lanes slots, so it should be fine to use it in the 16 lanes slots. Check the tech specs of the cards to verify.
So in very short:
- Slot 1: 16 lanes
- Slot 3: 16 lanes
- Pool A: 16 lanes
- Pool B: 16 lanes
About slots 1 to 4
Slots 1 to 4 are quite specific as these can host the 2 MPX modules. When the 2 MPX modules are connected, you won't be able to use any of these slots. And they are quite specific:- As explained above, slots 1 & 3 each have 16 lanes of PCIe 3.0 directly linked to the CPU. Indeed, as these slots are meant to host the graphics cards, you don't want them to have to share the bandwidth with other devices.
- Slots 2 and 4 share 8 lanes of PCIe 3.0 with the MPX connector. These 2 slots are used to provide PCIe bandwidth to the Thunderbolt ports that are available on the card. If you connect a "simple" graphics card only to slot 1 or 3, slots 2 and 4 should be available to provide 8 lanes of PCIe 3.0, that will be part of the 2 pools.
An unrelated problem I was looking at led me back to the RX6800 ROM posted by @Petri Krohn some months ago. Further digging shows that the RX6800 ROM assumes UEFI 2.x, while the MP5,1 provides an EFI 1.x+ environment. In particular, the EFI_HII_DATABASE_PROTOCOL (EF9FC172-A1B2-4693-B327-6D32FC416042) is not produced in the Mac Pro 5,1 EFI, but it is consumed by the RX6800 ROM, without error control - meaning the ROM looks for that protocol and stores the returned address (NULL, in this case) without checking the error code, then the ROM later uses that address without checking for NULL. This is almost certainly the cause of the "won't POST" problems with the RX6800; the code is jumping off into nowhere.
It should be fairly straightforward to write an auxiliary module that produces EFI_HII_DATABASE_PROTOCOL and the handful of other protocols the RX6800 expects; however, since this is running at PEI/DXE time, such a module would probably need to be flashed into either the RX6800 ROM or the Mac Pro BootROM in order to be available when it's needed. I doubt it's worth going down that path.
It should be fairly straightforward to write an auxiliary module that produces EFI_HII_DATABASE_PROTOCOL and the handful of other protocols the RX6800 expects; however, since this is running at PEI/DXE time, such a module would probably need to be flashed into either the RX6800 ROM or the Mac Pro BootROM in order to be available when it's needed. I doubt it's worth going down that path.
Does the GPU rom get executed before Driver#### is loaded? "won't POST" probably means it stops before getting to Driver####. In that case, a rom patch is required, preferably for the Mac Pro firmware so the PCIe card can still behave normally in a newer PC. APFS Rom Patch is an example of inserting drivers in the firmware of a Mac. The same method should work here?
If Driver#### can't work, is there a different nvram option that can affect early initialization? For example, PowerPC Macs used Open Firmware which had an nvram variable containing code that can be executed before or after PCI probing. It had another variable that can be used to skip PCI slots. Maybe a bios setting? Conceptually, there isn't much difference between nvram and firmware except nvram is easier to change.
I prefer the other way "flash the card"
1) Flash the card is very straight forward. IMO, easier and safer than flash the cMP. And it's so easy to flash the card back to it's factory state if we want to use that card in a modern PC later.
2) It's relative easy to recover a graphic card if that's badly flashed, especially for those dual ROM card (e.g. Sapphire PULSE RX6800). In many cases, we can actually recover the card via a cMP by using software only. But it's totally another story if we brick a cMP.
3) We can make one generic 6800 ROM for all cards (not desirable, but possible). But for cMP, we should dump and patch every single ROM for each cMP (due to it contain serial number etc). That's way more work to do. More work also means more chance of making error, and end up bricking some cMP.
Of course, if we can do something by simply using NVRAM option, or even boot loader (e.g. if OpenCore can load an alternate ROM from the EFI partition for the graphic card), that most likely will be safer than altering the firmware directly. However, using NVRAM option (even that exist) also means a NVRAM reset may stop the cMP to POST with any 6000 series GPU again. And the user must know how to recover, either by remote controlling a headless cMP, or by swapping in the emergency GPU.
I disagree with #3. We can programatically add the modifications to the current Mac firmware (keeping the serial numbers and other info intact). See the APFS Rom Patch as an example. The modifications for a 6800 ROM will have to be manually applied and each card may require a different rom.
AFAIK, you can't run code, as in a PEI module, from the NVRAM with the TIANO. It was possible back with CHRP and OpenFirmware. Btw, I read a tweet from the developer of Asahi Linux on M1 Macs (@marcan42) that M1 Macs have the same NVRAM design as CHRP.
Anyway, even if this is indeed possible, is an extremely bad idea. The NVRAM is the Achilles heel of MacPro5,1 and the available space is already insufficient as is with BigSur/Monterey, also will be a support nightmare with people doing NVRAM resets.
Not possible, with any NAVI2x GPU installed, tested with 6800XT and 6600XT, the MacPro won't POST at all.
Last edited:
From the case of HD7950, we can see that most cards (including HD7970 and 280X) from the same family can use the generic ROM. Of course tailor made the ROM for that particular card is always better, but clearly not always required.
Even each card need to be patched, patching the GPU ROM is still easier (IMO, also safer) than patching the cMP ROM (backup by point #1 and #2).
The NVMe bootability case (from memory, most of us never patch the cMP firmware by ourselves, at least, not on the 5,1, for APFS bootability) just proved that can be done, but not a case to prove that's easier or safer than flash a graphic card.
Of course, if you consider the value of a 5,1 vs 6800, then risk the 5,1 may be the smarter choice. However, for dual ROM 6800, I will say flashing the card still the smarter choice.
Understood, as expected.
A quick "back of the napkin" estimate is that the additional code/data required to provide the missing UEFI protocols would take 50k-300k (narrowing that range would require more analysis time than I'm willing to commit right now). If it ends up being at the low end of that range, it might be possible to juggle the padding in the BootROM and shoehorn the changes in. It would be tight, though. If it's at the high end of that range, some serious editing would be required, and it might be necessary to completely remove some existing modules (thereby losing support for whatever they provide - for example, could you live without FireWire support? And would the future owner of your Mac Pro agree?) - and this would also require more effort to ascertain that no dependencies get broken. I think I'm with @tsialex on this one - putting these additions in the BootROM is probably a bad idea.
The RX6800 ROM that I looked at appears to have adequate free space for the code/data, although more detailed analysis would be required to be certain. Hooking the code into the Option ROM chain should be straightforward. However, after another peek at the code, I don't think this would work.
The problem is that the very first thing the RX6800 ROM driver entrypoint does is look for those protocols (including at least one that's not present on the MP5,1) and blindly save their addresses, without looking for errors. It then sets up its driver binding protocol, which is how everything will communicate with it from that point forward. Because the entrypoint saved NULL protocol handler addresses, any attempt to connect or otherwise communicate with the RX6800 driver will result in a call to NULL, which won't end well. (At this point, it's fair to note that the RX6800 ROM is poorly written, and should definitely check for errors instead of blindly using uncertain values. An error return would at least allow the Mac Pro to issue a beep code or otherwise proceed with POST.)
That means the missing protocols must be in place before the RX6800 Option ROM is initialized, which means they need to be in the BootROM FFS (which seems to get initialized before any Option ROMs). And, as stated above, trying to squeeze this into the BootROM is probably a bad idea.
Unless someone (else) is willing to jump through a lot of flaming hoops, this looks like a dead end. An alternative for any aspiring Don Quixotes would be to re-work the RX6800 ROM to use the existing HII framework that's present in the MP5,1 BootROM. (A new video card and/or a new computer seems far more attractive. In fact, even a root canal seems more attractive. ;-)
The RX6800 ROM that I looked at appears to have adequate free space for the code/data, although more detailed analysis would be required to be certain. Hooking the code into the Option ROM chain should be straightforward. However, after another peek at the code, I don't think this would work.
The problem is that the very first thing the RX6800 ROM driver entrypoint does is look for those protocols (including at least one that's not present on the MP5,1) and blindly save their addresses, without looking for errors. It then sets up its driver binding protocol, which is how everything will communicate with it from that point forward. Because the entrypoint saved NULL protocol handler addresses, any attempt to connect or otherwise communicate with the RX6800 driver will result in a call to NULL, which won't end well. (At this point, it's fair to note that the RX6800 ROM is poorly written, and should definitely check for errors instead of blindly using uncertain values. An error return would at least allow the Mac Pro to issue a beep code or otherwise proceed with POST.)
That means the missing protocols must be in place before the RX6800 Option ROM is initialized, which means they need to be in the BootROM FFS (which seems to get initialized before any Option ROMs). And, as stated above, trying to squeeze this into the BootROM is probably a bad idea.
Unless someone (else) is willing to jump through a lot of flaming hoops, this looks like a dead end. An alternative for any aspiring Don Quixotes would be to re-work the RX6800 ROM to use the existing HII framework that's present in the MP5,1 BootROM. (A new video card and/or a new computer seems far more attractive. In fact, even a root canal seems more attractive. ;-)
@Syncretic
There are lot's of space available inside the BootROM, at least 1238344 contiguous bytes free, but all in the wrong areas
Maybe we could develop a PEI module to just load and relocate the EFI modules stored outside the FFS area?
There are lot's of space available inside the BootROM, at least 1238344 contiguous bytes free, but all in the wrong areas
Maybe we could develop a PEI module to just load and relocate the EFI modules stored outside the FFS area?
Hi guys,
Just want to ask for my brother as it is not my computer. He just bougth and installed a 6800 XT to his mac pro 2019 and it is detecting fine and being used. Howover when monitoring its usage it seems the % of GPU is much higher for the 580X which came with the machine. I know just becuase % is higher doesn't mean it is faster but is there anyway to ensure that the 6800 XT is priortise?
He did left the old GPU installed for the moment, that shouldn't have any negative impact in performance should it?
He is using mostly Adobe Premier. Thanks in advance.
Just want to ask for my brother as it is not my computer. He just bougth and installed a 6800 XT to his mac pro 2019 and it is detecting fine and being used. Howover when monitoring its usage it seems the % of GPU is much higher for the 580X which came with the machine. I know just becuase % is higher doesn't mean it is faster but is there anyway to ensure that the 6800 XT is priortise?
He did left the old GPU installed for the moment, that shouldn't have any negative impact in performance should it?
He is using mostly Adobe Premier. Thanks in advance.
