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

[diamond.g]

To add to that I am pretty sure all the highest binned cards (XTXH) are too long for the Mac Pro.

 

[LEOMODE]

Actually just realized if I use a non-MPX AMD card, I lose the top 2 USB-C ports, right? Assuming I take out the MPX module. That's a bummer.

Is there anyone who uses both the MPX module and new NAVI cards and sees if there is any conflict in either Mac OS or Boot Camp? On Boot Camp all I know is I can disable the card under Device Manager.

 

[flowrider]

^^^^No, you don't lose the "top USB-C ports". However, they stay as USB-C, you do lose TB.

Lou

 

[LEOMODE]

^^^^No, you don't lose the "top USB-C ports". However, they stay as USB-C, you do lose TB.

Lou

Ah, thanks for the correction! At least I still get the USB-C that's all it matters for the top ports hehe.

 

[joevt]

^^^^No, you don't lose the "top USB-C ports". However, they stay as USB-C, you do lose TB.

I think you just loose USB-C DisplayPort Alt Mode (for USB-C connections you still get USB 3.1 gen 2) and DisplayPort tunnelling (for Thunderbolt connections you still get 22 Gbps PCIe tunnelling).

 

[Petri Krohn]

If it's an AVX issue...

I guess the first thing to try might be to patch the GPU firmware. First, try to just no-op the gop.

Classic Mac Pros do not need EFI firmware to use a graphics card. Modern versions of macOS can read the Device ID from the VBIOS part of the firmware.

The simple thing to do would be to reflash the card with the EFI rom image removed and only the legacy VBIOS rom image on the EEPROM chip.

Since with a NAVI GPU present the Mac Pro wouldn't past POST...

Btw, I searched all major hackintosh sites when I looked at this issue, at the time no one reported a NAVI GPU working with a Westmere Xeon and the oldest hack that I read about was Xeon E5-V4 from the Broadwell-EP family.

If this was an AVX issue, then it should apply to Windows PCs as well. Or maybe not. Westmere generation PCs seldom have UEFI firmware. They would only see the legacy VBIOS part.

P.S.

I saw a large number of reference design RX 6800s and RX 6900s suddenly appear on a second-hand marketplace in Finland. All new in unopened boxes. The sellers had ordered them directly from AMD and paid the low official price. Evidently they were all delivered at the same time months later. People are selling them now, as they have already bought some other GPU. (Nvidia, most likely.)

The reference design Radeon RX 6800 is the only RX 6000 series model that will fit inside a classic Mac Pro without blocking Slot 2. If you want one, now is the time to look at marketplaces for used cards.

 

[Spacedust]

I was able to run Gigabyte RX6800 as eGPU for Mac Pro 6,1 and works just great under Big Sur 11.6.

 

[andrewkhoo]

The reference design Radeon RX 6800 is the only RX 6000 series model that will fit inside a classic Mac Pro without blocking Slot 2. If you want one, now is the time to look at marketplaces for used cards.

Hi @Petri Krohn , mind if I ask, what other 3rd party manufacturer's 6800 / 6800XT GPU will fit the classic Mac Pro length-wise? (I'm OK with it blocking the Slot 2, but not slot 3)

And also, does reference 6800XT fit the classic Mac Pro length-wise?

Thank you in advance!

 

[mikas]

Don't know about third party card thicknesses or dimensions. AMD 6800 and XT will fit in a cMP, but beware it most probably won't work in a cMP, not even with the latest Big Sur with drivers. At least Macschrauber had tried that already:
6800 XT in cMP
6900 XT in cMP won't POST
AMD series 6000 won't boot

 

[andrewkhoo]

Don't know about third party card thicknesses or dimensions. AMD 6800 and XT will fit in a cMP, but beware it most probably won't work in a cMP, not even with the latest Big Sur with drivers. At least Macschrauber had tried that already:
6800 XT in cMP
6900 XT in cMP won't POST
AMD series 6000 won't boot

Thank you for the heads up, @mikas. I guess it's "back to searching high and low for 5000 series GPU" and trying not to have a heart attack.... ?

 

[flowrider]

Don't know about third party card thicknesses or dimensions. AMD 6800 and XT will fit in a cMP, but beware it most probably won't work in a cMP, not even with the latest Big Sur with drivers. At least Macschrauber had tried that already:
6800 XT in cMP
6900 XT in cMP won't POST
AMD series 6000 won't boot

Yes, it will not work in a cMP:

AMD Radeon RX 6800 XT / 6900 XT for macOS?

Before. AFAIK, everyone that tested a NAVI GPU also tried with an AppleOEM GPU present to see if it would work, none got it working. Since with a NAVI GPU present the Mac Pro wouldn't past POST, maybe the next test that should be done is with an eGPU. Not much practical or economical sense...

forums.macrumors.com

Lou

 

[andrewkhoo]

Yes, it will not work in a cMP:

AMD Radeon RX 6800 XT / 6900 XT for macOS?

Before. AFAIK, everyone that tested a NAVI GPU also tried with an AppleOEM GPU present to see if it would work, none got it working. Since with a NAVI GPU present the Mac Pro wouldn't past POST, maybe the next test that should be done is with an eGPU. Not much practical or economical sense...

forums.macrumors.com

Lou

Thank you! Prices for 5700 xt in Malaysia are bonkers/prohibitive. (that was the reason I was considering of hunting for a 6000 series)

 

[Petri Krohn]

Update: As @Syncretic points out below, this analysis is incorrect. The Intel firmware image does not use AVX instructions.

CONFIRMATION: The Radeon RX 6800 / 6900 series EFI uses AVX instructions

I downloaded the VBIOS file for the reference design RX 6800 from the TechPowerUp site. I opened the file in Hex Fiend. It contains two EFI sections, starting at addresses 0xAA00 and 0x14000. Both are labeled "GOP AMD REV: 000.000.000.020.001 2182337 537937" in cleartext.

I then opened the VBIOS file in Hopper Disassembler 4 and searched for "YMM" and "ZMM". There are a total of 21 instances of AVX calls in the two EFI sections. The legacy BIOS section only contains references to the 128-bit XMM registers, so it should execute in older processors with the SSE instruction set.

vpacksswb is a 256-bit version of the PACKSSWB — Pack with Signed Saturation instruction from the SSE instruction set.

One must somehow prevent the EFI firmware of classic Mac Pros from loading the GOP EFI code. One way could be to flash the card with the EFI code removed and only the legacy BIOS left in the firmware file.

Classic Mac Pros do not need EFI firmware to use a graphics card. Modern versions of macOS can read the Device ID from the VBIOS part of the firmware.

If it's an AVX issue, then I wonder if an instruction emulator can be added to UEFI (like AAAMouSSE except for UEFI and AVX)? You would need a way to make that load before the GPU firmware.

One would need to allocate space for the first 128 bits of the YMM/XMM registers. One would then need to catch each instance when the floating point and SIMD registers are stored to the stack and insert the additional register parts. This could maybe be done in an operating system kernel. But does EFI even have a kernel?

I guess the first thing to try might be to patch the GPU firmware. First, try to just no-op the gop.

As far as I can tell, all the AVX instructions used are 256-bit versions of the 128-bit SSE commands. In theory each one of them could be replaced with two or four consecutive calls to corresponding SSE instruction. If only 8 YMM or XMM registers were used, one could map each YMM register to two consecutive XMM registers in the 16-long register file. Unfortunately all registers except YMM15 are used. However, if the YMM usage is local and the registers do not carry global state, one might be able to get away with reusing XMM registers.

 

[tsialex]

CONFIRMATION: The Radeon RX 6800 / 6900 series EFI uses AVX instructions

I downloaded the VBIOS file for the reference design RX 6800 from the TechPowerUp site. I opened the file in Hex Fiend. It contains two EFI sections, starting at addresses 0xAA00 and 0x14000. Both are labeled "GOP AMD REV: 000.000.000.020.001 2182337 537937" in cleartext.

I then opened the VBIOS file in Hopper Disassembler 4 and searched for "YMM" and "ZMM". There are a total of 21 instances of AVX calls in the two EFI sections. The legacy BIOS section only contains references to the 128-bit XMM registers, so it should execute in older processors with the SSE instruction set.

View attachment 1853669

vpacksswb is a 256-bit version of the PACKSSWB — Pack with Signed Saturation instruction from the SSE instruction set.



One must somehow prevent the EFI firmware of classic Mac Pros from loading the GOP EFI code. One way could be to flash the card with the EFI code removed and only the legacy BIOS left in the firmware file.

Classic Mac Pros do not need EFI firmware to use a graphics card. Modern versions of macOS can read the Device ID from the VBIOS part of the firmware.



As far as I can tell, all the AVX calls are 256-bit versions of the 128-bit SSE commands. In theory each one of them could be replaced with two or four consecutive calls to corresponding SSE instruction. If only 8 YMM or XMM registers were used, one could map each YMM register to two consecutive XMM registers in the 16-long register file. Unfortunately all registers except YMM15 are used. However, if the YMM usage is local and the registers do not carry global state, one might be able to get away with reusing XMM registers.

That explains why no one ever got a NAVI 2x GPU running with anything earlier than Ivy Bridge Xeons.

Since it is now confirmed (see post #800) that AMD started to require AVX with NAVI 2x GPUs just like the datacenter versions (for example the Instinct accelerator line), perhaps another requirement of the later cards could also trickled down, PCIe v3.0 Atomics/Read-Modify-Write Transactions.

 

[joevt]

One way could be to flash the card with the EFI code removed and only the legacy BIOS left in the firmware file.

This is what I meant by noop the gop. Just change the byte in the PCIe header so the EFI image is no longer marked as an EFI image so it won't get loaded.

 

[startergo]

This is what I meant by noop the gop. Just change the byte in the PCIe header so the EFI image is no longer marked as an EFI image so it won't get loaded.

One might make sure such a change does not instigate checksum recalculation.

 

[LEOMODE]

Just got a AMD reference 6900XT. Easy plug n play, works with both Big Sur and Boot Camp Windows 10 off the box, and super quiet (even quieter than 3090 FE at full load). The only thing missing from Apple’s OEM’s W6900X is the thunderbolt ports, air ventilation tailored for 7,1 and last but not least $5000+ more intangible premium

I did notice something on my 6900XT though, I have a triple monitor setup at 4k 144hz, and usb-c port connected display sometimes do not wake up only on Bug Sur (Boot Camp is fine) unlike display port connected displays. Also I only see 95hz as maximum.

Does anyone have the same issue?

 

[joevt]

Just got a AMD reference 6900XT. Easy plug n play, works with both Big Sur and Boot Camp Windows 10 off the box, and super quiet (even quieter than 3090 FE at full load). The only thing missing from Apple’s OEM’s W6900X is the thunderbolt ports, air ventilation tailored for 7,1 and last but not least $5000+ more intangible premium

I did notice something on my 6900XT though, I have a triple monitor setup at 4k 144hz, and usb-c port connected display sometimes do not wake up only on Bug Sur (Boot Camp is fine) unlike display port connected displays. Also I only see 95hz as maximum.

Does anyone have the same issue?

Is it the LG 27GN950-B? I think it require DSC for 144Hz. macOS does not enable DSC by default since Big Sur for third party displays. Use Catalina or complain to Apple.

Maybe try setting DisableDSC to 0 (no one has reported trying this yet)
https://forums.macrumors.com/thread...ransfers-recommendation.2278473/post-30189995
https://forums.macrumors.com/threads/diy-5k-monitor-success.2253100/post-30255292
https://forums.macrumors.com/thread...ro-egpu-1-or-2-displays.2307784/post-30183809

 

[LEOMODE]

Is it the LG 27GN950-B? I think it require DSC for 144Hz. macOS does not enable DSC by default since Big Sur for third party displays. Use Catalina or complain to Apple.

Maybe try setting DisableDSC to 0 (no one has reported trying this yet)
https://forums.macrumors.com/thread...ransfers-recommendation.2278473/post-30189995
https://forums.macrumors.com/threads/diy-5k-monitor-success.2253100/post-30255292
https://forums.macrumors.com/thread...ro-egpu-1-or-2-displays.2307784/post-30183809

The model is correct. Got it no wonder. But I do recall it worked before. I guess Apple disabled it in the latest update. Just don’t understand why they would only allow 95hz though. It could’ve been like 60hz, 120hz, 144hz, etc. 95hz looks random.

 

[joevt]

The model is correct. Got it no wonder. But I do recall it worked before. I guess Apple disabled it in the latest update. Just don’t understand why they would only allow 95hz though. It could’ve been like 60hz, 120hz, 144hz, etc. 95hz looks random.

95Hz is the max for 4K 10bpc RGB using HBR3 x4 connection without DSC. You could try adding a custom resolution of 4K120 using CVT-RB2 timing in SwitchResX but that will be limited to 8bpc (no HDR).

 

[Jeekee]

That explains why no one ever got a NAVI 2x GPU running with anything earlier than Ivy Bridge Xeons.

Since it is now confirmed that AMD started to require AVX with NAVI 2x GPUs just like the datacenter versions (for example the Instinct accelerator line), perhaps another requirement of the later cards could also trickled down, PCIe v3.0 Atomics/Read-Modify-Write Transactions.

Probably a stupid remark from me, but how about a i7-980X/990X? These are able to handle AVX code right? Or will these get stuck because of the bridge not being able to handle the code or the memory address assignment?

cheers

 

[tsialex]

Probably a stupid remark from me, but how about a i7-980X/990X? These are able to handle AVX code right? Or will these get stuck because of the bridge not being able to handle the code or the memory address assignment?

cheers

You could get your answer from ARK - no AVX support for any Westmere, i7-980X/990X are Westmere, from the family Gulftown, i7-990X is just a rebadge of a W3690 with the 1333MHz frequency support disabled on the memory controller.

No LGA1366 processor have AVX support.

 

[Jeekee]

You could get your answer from ARK - no AVX support for any Westmere, i7-980X/990X are Westmere, from the family Gulftown, i7-990X is just a rebadge of a W3690 with the 1333MHz frequency support disabled on the memory controller.

No LGA1366 processor have AVX support.

I am probably mixing up things but AVX is part of SSE4.2 right? At least that’s what intel ark says. So what am I missing here?

 

[tsialex]

I am probably mixing up things but AVX is part of SSE4.2 right? At least that’s what intel ark says. So what am I missing here?

No, it's not - it's a different instruction set extension.

This is from MP6,1 E5-2697:

 

[Syncretic]

CONFIRMATION: The Radeon RX 6800 / 6900 series EFI uses AVX instructions

I downloaded the VBIOS file for the reference design RX 6800 from the TechPowerUp site. I opened the file in Hex Fiend. It contains two EFI sections, starting at addresses 0xAA00 and 0x14000. Both are labeled "GOP AMD REV: 000.000.000.020.001 2182337 537937" in cleartext.

I then opened the VBIOS file in Hopper Disassembler 4 and searched for "YMM" and "ZMM". There are a total of 21 instances of AVX calls in the two EFI sections. The legacy BIOS section only contains references to the 128-bit XMM registers, so it should execute in older processors with the SSE instruction set.

View attachment 1853669

vpacksswb is a 256-bit version of the PACKSSWB — Pack with Signed Saturation instruction from the SSE instruction set.

One must somehow prevent the EFI firmware of classic Mac Pros from loading the GOP EFI code. One way could be to flash the card with the EFI code removed and only the legacy BIOS left in the firmware file.

Classic Mac Pros do not need EFI firmware to use a graphics card. Modern versions of macOS can read the Device ID from the VBIOS part of the firmware.



One would need to allocate space for the first 128 bits of the YMM/XMM registers. One would then need to catch each instance when the floating point and SIMD registers are stored to the stack and insert the additional register parts. This could maybe be done in an operating system kernel. But does EFI even have a kernel?



As far as I can tell, all the AVX instructions used are 256-bit versions of the 128-bit SSE commands. In theory each one of them could be replaced with two or four consecutive calls to corresponding SSE instruction. If only 8 YMM or XMM registers were used, one could map each YMM register to two consecutive XMM registers in the 16-long register file. Unfortunately all registers except YMM15 are used. However, if the YMM usage is local and the registers do not carry global state, one might be able to get away with reusing XMM registers.

Unfortunately, this is not quite the case.

The linked VBIOS file contains three segments: Non-EFI at 0x00000, x86_64 EFI at 0x0aa00, and ARM64 EFI at 0x14000. Both the x86_64 and ARM64 segments are compressed - the disassembly shown above is nonsensical, working from compressed data (note the non-instruction bytes intermingled with the instruction stream, and just try to follow the logic of the "instructions"). Decompressed, the x86_64 segment does not appear to contain any AVX instructions. (I only spent a few moments looking at this, so I could be wrong.)

I have attached the decompressed EFI segments, in case anyone cares to dig deeper (not having a 6800/6900 card, I don't have a dog in this race ;-)

EDIT: Also, when searching for AVX instructions, it's more useful to search for opcodes beginning with 'v' instead of just YMM/ZMM - virtually all of the SSE instructions are mirrored in AVX, so there are a great many AVX instructions that only operate on the XMM registers, and a "YMM/ZMM" search would overlook those.

Non-EFI header detected at 0x00000000.
   Block length 85 (43520 bytes) (0x0000aa00)
   Unknown1: 0xe9 (233)
   Initialization Entrypoint: 0x244e
   PCIR offset: 0x036c
   Expansion header offset: 0x0000
   PCIR structure at 0x0000036c:
      Vendor ID: 0x1002 (AMD/ATI)
      Device ID: 0x73bf
      Vital Data Offset: 0x0000
      PCIR structure length: 0x0018
      PCIR structure revision: 0x0000
      PCIR class code: 0x000003
      PCIR image length: 85 blocks (43520 bytes) (0x0000aa00)
      Revision level of code/data: 0x1401 (5121)
      Code type: 0x00 (Non-EFI)
      Indicator: 0x00 (more records follow)
SAVECODE: offset 0x00000384, len 42620 (0x0000a67c)

EFI header detected at 0x0000aa00.
   Initialization Size: 75 blocks (38400 bytes) (0x00009600)
   EFI signature: 0x0ef1
   EFI subsystem: 0x000b (Boot Service)
   EFI machine type: 0x8664 (x86_64)
   Compression type: 1 (Compressed)
   EFI image offset: 0x0064 (0x0000aa64)
   PCIR offset: 0x001c
Code successfully uncompressed into 'AMD.RX6800.16384.201007.rom.x86_64.EFIrom'
   PCIR structure at 0x0000aa1c:
      Vendor ID: 0x1002 (AMD/ATI)
      Device ID: 0x73bf
      Vital Data Offset: 0x0000
      PCIR structure length: 0x0018
      PCIR structure revision: 0x0000
      PCIR class code: 0x000003
      PCIR image length: 75 blocks (38400 bytes) (0x00009600)
      Revision level of code/data: 0x0000 (0)
      Code type: 0x03 (EFI)
      Indicator: 0x00 (more records follow)

EFI header detected at 0x00014000.
   Initialization Size: 78 blocks (39936 bytes) (0x00009c00)
   EFI signature: 0x0ef1
   EFI subsystem: 0x000b (Boot Service)
   EFI machine type: 0xaa64 (ARM64)
   Compression type: 1 (Compressed)
   EFI image offset: 0x0064 (0x00014064)
   PCIR offset: 0x001c
Code successfully uncompressed into 'AMD.RX6800.16384.201007.rom.ARM64.EFIrom'
   PCIR structure at 0x0001401c:
      Vendor ID: 0x1002 (AMD/ATI)
      Device ID: 0x73bf
      Vital Data Offset: 0x0000
      PCIR structure length: 0x0018
      PCIR structure revision: 0x0000
      PCIR class code: 0x000000
      PCIR image length: 78 blocks (39936 bytes) (0x00009c00)
      Revision level of code/data: 0x0000 (0)
      Code type: 0x03 (EFI)
      Indicator: 0x80 (no more records)