Gigabyte B550 Vision D (Thunderbolt 3) + AMD Ryzen 7 3700X + AMD RX 5600 XT

[Middleman]

Hm. Is there a Mac with current(6800) gen AMD GPU? Otherwise, why would anyone at Apple or AMD bother?

Not yet (afaik) but there's PLENTY of Apple users out there who happen to use eGPU setups which require the speed/spec of the cards (not just MP users). Lots of heavy users and content creators, so they have to bother with the updates - if not Apple at least with AMD.

 

[zipb]

Is a M1 Mac compatible with eGPU?

 

[zipb]

I just had a look, eGPU's are compatible with a M1 Mac in the sense that they show up in Big Sur, but there's no acceleration. General consensus on the GPU forum: eGPU's will go the way of the dodo.

So I guess this (proper drivers for latest AMD GPU's) will not be high on the list of (at least) the Apple engineers. And without Apple's active help, writing drivers is tough.

On the other hand, it might not be hard for AMD to update the driver to the latest gen cards so these can be an expensive option for a Mac Pro 2019.

 

[maclinuxg4]

Is a M1 Mac compatible with eGPU?

Not now, and may be according to the decision of Apple.

 

[CaseySJ]

MacOS Big Sur already contains device IDs for AMD RX 6800, 6800XT, and 6900XT among others. However the driver classes for these GPUs are still missing.

Remember that macOS and all other PCI-compliant operating systems always scan the PCI bus for all devices attached to the system, query the Device and Vendor IDs from each device, then look for drivers that support those IDs.

In MacOS this is typically specified in a kext info.plist by a property called IOPCIPrimaryMatch. Because there are a large number of kexts in the system and each kext matches different sets of device IDs, there arises the concept of the “kernel cache”.

If you recall, the “kextcache” command is applied to /L/E and /S/L/E that both contain kexts. The kernel cache builds an optimized driver dependency tree that is used not only to match device IDs to their kexts, but also to determine which kexts depend on which sub-kexts.

For example, WhateverGreen is a plug-in for Lilu, so it depends on Lilu. Although we don’t install Lilu and WEG in /L/E any longer and therefore they are omitted from the kernel cache, they are nevertheless a good example of a dependency relationship.

So the fact that PCIe device IDs for all AMD 6000-series variants are already present in Big Sur is, to say the least, interesting...

 

[zipb]

MacOS Big Sur already contains device IDs for AMD RX 6800, 6800XT, and 6900XT among others. However the driver classes for these GPUs are still missing.

Remember that macOS and all other PCI-compliant operating systems always scan the PCI bus for all devices attached to the system, query the Device and Vendor IDs from each device, then look for drivers that support those IDs.

In MacOS this is typically specified in a kext info.plist by a property called IOPCIPrimaryMatch. Because there are a large number of kexts in the system and each kext matches different sets of device IDs, there arises the concept of the “kernel cache”.

If you recall, the “kextcache” command is applied to /L/E and /S/L/E that both contain kexts. The kernel cache builds an optimized driver dependency tree that is used not only to match device IDs to their kexts, but also to determine which kexts depend on which sub-kexts.

For example, WhateverGreen is a plug-in for Lilu, so it depends on Lilu. Although we don’t install Lilu and WEG in /L/E any longer and therefore they are omitted from the kernel cache, they are nevertheless a good example of a dependency relationship.

So the fact that PCIe device IDs for all AMD 6000-series variants are already present in Big Sur is, to say the least, interesting...

If you look at the history of device id's, 100% of them got a driver at some point? Or is it more like a reservation system with (possibly) no shows?

 

[CaseySJ]

If you look at the history of device id's, 100% of them got a driver at some point? Or is it more like a reservation system with (possibly) no shows?

I think the reverse is also worth considering, namely:

If there was no intention of supporting a particular device, would Apple include device IDs for the entire set of those devices in their latest operating system?

There are a huge number of PCIe devices on the market, but only a tiny fraction are listed in macOS drivers. Only those devices that are (a) either supported or (b) may soon be supported are specified in those files. Does this mean that category (b) devices will certainly be supported? No. But it does indicate a strong possibility.

Rumors suggest that one last Intel-based update of the Mac Pro will occur. It makes sense that professionals who require high graphics performance, and hence purchase dual-Vega modules, would demand support for AMD RDNA 2.

Here is an excerpt from /System/Library/Extensions/AMDRadeonX6000Framebuffer.kext (info.plist):

• The hex numbers are in the form: 0x [device ID] [vendor ID]
• For example, 0x73BF1002 (2nd item on line 2) means:
  • Device ID = 73BF (this is AMD 6800XT I believe)
  • Vendor ID = 1002 (this vendor ID permanently assigned to "AMD")

 

[zipb]

Maybe. How did the support of NVIDIA end? No sign of x0x0 device id's in a previous version of MacOS?

 

[CaseySJ]

Maybe. How did the support of NVIDIA end? No sign of x0x0 device id's in a previous version of MacOS?

Support for some Nvidia GPUs such as GTX 680, GTX 780, and GTX 8800 that were natively supported has not ended. As far as I know, they support OpenCL, but not Metal. Newer models are not mentioned or supported.

 

[zipb]

So there are no pulled out references? I understand they are no longer referenced in Big Sur, but no NVIDIA device (class) id's ever showed up that were not followed by a driver (class) implementation?

Not that I care much for a new graphics card with the current prices.