Why there is no more support for third party graphics cards?
because the primary structure of macOS does not revolve solely around the Mac Pro. Never did previously either.
The whole idea of this kind of machine is the ability to upgrade afterwards. Sure, the integrated GPU is excellent for almost everybody, but this is what I think Apple should do with this product:
....
1. Ability to upgrade the graphic card with a third party one. The driver should me provided by AMD or NVidia, and in that way when the time makes your gpu slow, just add a new graphics card, install the drivers and voilá.
Pragmatically, it really is not 'voilá'. "just drivers" has lots of presumptions built into it that don't hold up. First, GPU drivers tend to be somewhat 'leaky' abstractions of the resource. Meaning it isn't really one , 100% uniform interface for multiple different GPUs. Optimizations and workarounds tend to be required for software that is going to push the hardware to performance limits. Or not even uniform at all in example where applications are using vendor specific API ( CUDA).
Furthermore, in the OpenGL era Apple did about 'half' the work on the stack and the GPU vendors did about 'half'. It varied widely by vendor but it wasn't anything like Apple does 1% and the vendors did 99%. For example, toward the end of their relationship, Nvidia drivers would "halt and catch fire' every time Apple came out with a substantive OS update. That is because uncoordinated changes to the kernel and the GPU drivers had potential of not working well, so the drivers erred on side of caution ( plus it helped to throw gas on the fire in the feud between the two).
There is a coordination between OS vendor , GPU driver writer , and software app developers that requires cooperation between all of the parties. For example, Intels problems when they launched discrete Arc GPUs.
After an initial rough start, Intel has released new drivers for its Intel Arc GPUs. We retested the Intel Arc A770 to see how it performs with the new drivers and to see if there are still any bugs to work out.
www.pcworld.com
One major issue that Intel had was that their driver and software writteen to their driver presumed/assumed shared, unified RAM like overhead and the discrete cards did not have that. They tried to 'paper over' that by using Re-sizable BAR, but didn't work as cleanly as they hoped ( nor were some systems implementing it effectively). In PC land there are lots of assumptions/presumptions that PCI-e data traversals are relatively slow and software is skewed/optimized to overcome that issue.
The major factor is the general driver model is changing with M-series. Apple direction forward is to kick all non Apple stuff out of kernel space for security (and control) issues. DriverKit stuff lies in an 'in-between' land where drivers are given privilege address space , but a space outside the kernel. There are additional security upsides in that drivers are just as isolated from each other as they are from the kernel. So the old school macOS drivers are not going to work the same way in the new system. ( It is not a completely 'already solved' problem. ) . [ Drivers no inside the kernel are also much easier to debug and develop. ]
"Apple shouldn't kick everyone else out of the kernal". Well outcomes like these suggest otherwise.
"... Over the past 10 days,
CrowdStrike and
Microsoft have been working around the clock to help customers affected by the
massive Windows BSOD issue caused by a
faulty CrowdStrike update. ..."
Microsoft outlined several built-in security features in Windows and plans to collaborate with the anti-malware ecosystem for improved security. They're also developing safer rollout strategies.
www.neowin.net
One bad driver in the kernel idled a whole host of companies for days! Apple is trying to build the "you can trust us for privacy and security" ... meanwhile Windows is offline for over a week. You will probably have lots of trouble trying to change Apple's mind on this path.
Splitting up the driver stack got even more skewed with Metal. Where Apple took control of 90+% of the stack and the GPU vendors provision low level compilers and optimization help.
In the entire rest of the Mac line ( and all of the iPad and iPhone line ups), Apple CPUs and Apple GPUs talking to each other inside of a 100% Apple kernel isn't a problem. That is largely why things are heading that way.
Throw on top Apple abandoning open standards for graphics and compute ( deprecated OpenGL , OpenCL , etc). Pragmatically, Metal became a "embrace , extend , extinguish" , proprietary API. Apple was burnt by unwieldy committees and so have chosen to bypass them. (e.g., Nvidia dragging their feet on OpenCL adoptions evolution , in part to build a bigger moat around CUDA). Microsoft did their share of moat building also ,but left enough of a pluggable graphics stack API behind to not squeeze out options like OpenGL/Vulkan/etc. But Windows has no real phone presence anymore. Apple's breadth of ecosystems is different.
DriverKit drivers for PCI-e cards that are "compute accelerators" would likely work. Avoid intertwining with the Graphics output stack and things that Apple has 95+% control over and likely can "plug in" in a voilá fashion.
2. RAM Slots. Yes, I know, the RAM is integrated into the processor, but what about secondary ram? The idea is to use those ram sticks as a fast virtual space for RAM instead of disk. That should increase performance when you run out of ram because the computer becomes old.
First, 'old age' doesn't make RAM shrink. People get shorter with age (cartilage changes , bone changes , etc) . RAM stays the same size. New workloads might get bigger , but workloads changed, not the RAM.
Two issues. One is software again. The more pronounced the NUMA effect , the more likely those effects will trickle through and puncture the abstractions that presume uniform access. Very good chance Apple won't let RAM that might interact with the GPU (or NPU or DisplayControllers) interact with this as the latency hit would be substantive. macOS has a mechanism which compresses RAM pages of apps that are not used, but inactivity is a special corner case. Latency is much less of an issue if 'no one' is using the resource. ( i'd be surprised if the idle compression thing touched the GPU/NPU/etc shared, unified pages. )
Conceptually the compression could be mostly transparently combined with moving to "one hop" RDIMMs (secondary RAM). Even compressed RAM pages still take up space.
Probably a bit more generally useful would be to turn the secondary RAM into a "RAM SSD". So virtual memory paging could/would go there first. Or possibly could use RAM SSD shift a substantial amount of the disk cache workload out of the primary RAM. ( if have a largish capacity Mac, open Activity Monity after doing substantive work and look at the Memory tab and the cached file amount. It is usually more than a few GBs. If just moved that somewhere else , would have more RAM)
Apple already has some software to create a RAM disk (that is mostly disused, but it could be a start).
The large problem though is that Apple's "poor man's HBM" that they use for the primary memory takes up a very large amount of edge space of the chips. There really isn't room for "another" memory controller to a different kind of RAM on the die. You could use something like UltraFusion connector to get to yet another die, but that other die could have more CPU/GPU/NPU cores that would need another primary memory controller set. It would have to be some die that was smallish and just punted on more cores and just did more I/O. Folks handwave that Apple will need a "AI server" SoC , but is that package going to punt on more cores? Probably not.
This is a bit of tail-wag-dog path where trying to create RAM DIMM slots just so can fill them versus anything at harmony with Apple's general design parameters.
At best might end up with some SOCAMM derivative that Apple comes up with for the semi-custom RAM packages they use. Even if got something to 'replace' , it likely would not be a standardized commodity part.
3. Upgradable CPU. Yes, the ability to take out your current M2 or M4 to install an M5 or M6. In that way, the first 2 options become obsolete. Need better CPU or GPU or more RAM? Or the three of them? Just buy another CPU Card and make your mac great again.
The Mac Pro 2010-2012 didn't get non-obsolete CPUs later. Folks might have moved from 6 cores to 12 cores but the tech inside the cores was the same. The MP 2019 was a 'dead end' Intel socket. There wre no new 'technology' cores coming to those. Changing the core count is mainly re-shuflling the deck chairs on the ship ; not a new tech ship.
4. What the nurmac says... I didn't realized that Apple didn't support NVMe directly
It is more "OCD control" quest than NVMe. There are several folks obsessed with removing or pushing aside Apple's primary boot drive SSD. That drive isn't NVMe. The security protocols of Macs make it so that drive is integral to the boot process (if only for the first couple of steps).
If someone presents a modular focused solution that was more secure than Apple's it might get traction. But what the push here is for is modularity over security. It is unlikely Apple is going to 'buy' that.
Apple does have "homework" to do on just supporting NVMe drives in general.
Hey guys, I am havining an inconsistant issue with both my NVME drive adapters intermittingly failing to mount on my 2019 Mac Pro on Monterey 12.6. I'm constantly having to restart the machine to get the drives to mount. No drive issues or fails via Disk Utility and just gives 'Invalid Disk'...
forums.macrumors.com
Apple likes to pretent that nobody but their own SSD's are worthy. ( ignoring Trim and other backhanded lack of support). That whole attitude would have to change 180 degress before any chance would commit to a boot drive.
There is another whole Mac Pro forum thread on bootable enterprise card/drive problems, that again is a OS suppose scope issue more so than a core boot firmware one. There are more than few things that assume UEFI like boot enviroment and quirks gets exposed when there isn't one. ( Apple isn't going to backtrack to UEFI ).
