I know the advantages of Apple Silicon vs Intel, read my post again. I said an Intel Mac Pro with an updated afterburner card with Apple Silicon. Essentially a dual architecture system.There's no point in the afterburner card anymore. The thing was made into retroware the moment the M1 Pro came out with it's Media Engine. The Media Engine in Apple Silicon does everything the afterburner card did but better and faster in a low wattage package, and the M2 Ultra is equivalent to 7 of these cards.
![M1-Max-ProRes-benchmark.jpg]()
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 14,8 The future of Mac Pro
- Thread starter Xenobius
- Start date
- Sort by reaction score
Fragmentation wouldn’t exist, both would be integrated and MacOS would manage what to use when needed. Native x86 applications could run, PCI graphics cards could still be used and Windows applications could still run without needing hardware emulation.
You say "...then there's the lowly mac trudging along, and the pro a tiny sliver of that." But Macs are the fourth largest computer sales in the world, which is hardly lowly. My guess is Macs are fourth in worldwide personal computer sales but likely first in profitability and general tech excellence.
Do not diss the Mac. $3T Apple can walk and chew gum at the same time. My guess is we will see Apple continue to develop M3/M4 SoC to grow MP performance.
You describe a very slick solution that presents all kinds of possibilities. Such a card would create a furnace but the folks that use such apps seem to like adding heat to the planet, and the base MP could remain civilized from an energy standpoint.
A card like that could bridge the years it will take for users to learn to take advantage of M3/M4/M5 Apple SoC in future generations of Mac Pro.
What you are describing is fragmentation. You are putting all the burden on the developers who have to maintain multiple codebases and algorithms to get the best out of the hardware. That is certainly not in Apples interest.
Posts like these remind me of what Jobs said when he returned to Apple. Sub the Java for ARM/Apple silicon, and put any apple executive for Jobs.
Apple knows it can’t please every one, that’s how they almost ended up closing shop.
Last edited:
I am just not sure that you are getting it, the machine would run native Intel AND native Apple Silicon, the developer would have no burden at all. Mac OS would determine what architecture to run.
Why would Apple put one foot forward and another stuck in the past. It isn’t a cohesive strategy. They will go all in on Appple silicon.
Yes, that is probably the way that Apple sees it. Apple most likely plans on letting the power of M3/M4/M5 performance draw devs to the Apple platform. However IMO fragmentation will happen no matter what. If (as is likely) Apple does not create some variant of a dual solution such as Spock suggested, then the market will fragment as it already is doing, and users of the top end of MP lose.
I think you are correct that Apple will go all in on their own SoC, but I like Spock's idea as an interim bridge for users.
Apple will probably support Intel MP till 2027-2028. That’s plenty of time to beef up M4 or M5 ultra. But expect some of the new features to be AS only.
Apple Developers for Mac OS itself will have 2 sets to maintain with different capabilites depending upon the underlying Platform.
Media Engine and Neural Engine would need to be added to the Intel Systems and as not part of the SoC will they need to be different to account for the difference in accessing the memory from an Add On Board or will they implement the functionality using Metal API on GPU's in which case yet further differences in Mac OS that would need to reflect in the Mac OS code base and frameworks.
With Handbrake then the Mac OS version didn't get the capability to use the QuickSync in the Intel CPU for quite some time until VideoToolBox exposed the ability to use without having to code specifically for the QuickSync.
If was on a T2 equipped Mac such as Mac Pro's which don't have QuickSync then then VideoToolBox would use the T2 instead or if on an older one such as a Mac Pro 5,1 then would send to the GPU card to do the HWEncoding.
All that has to be maintained and coded in the OS and Framework so that App Developers don't have to code for the difference.
Is why Apple didn't continue to support PPC for years and years after switch to Intel or keep Power versions as there was certainly nothing wrong with G5 for the PowerMac. Was the Laptops that Apple had problem with. Could have kept the PowerMac on the Power Architecture and look how powerful the Power Architecture became and the type of computers used in. Just moved Laptops to Intel.
Not any different to what you are suggesting here with keeping Mac Pro on Intel.
Fully agreed expect some of the new features to be AS only. I am a big fan of Apple's Unified Memory Architecture and have high hopes for Apple wowing us with some cool new chip architectural tricks concurrent with M3 and beyond.
Jumping into this late, but I recorded my thoughts on youtube but to save everyone Mac Rumors a click, if Apple at least goes through with the iGPU/dGPU patent, perhaps the Mac Pro has a future.
Last edited:
You're Greg? I love your videos!! I have this somewhat pointless obsession with increasingly longevity of 1-5,1 Mac Pros...
Yep and thanks! I'm 99.99% a lurker here, hence the upgrade guides being a series of links to the Mac Rumor forums.
As far as pointless obsessions, I can relate.
That’s not a dGPU patent. That parent discusses work scheduling across multiple GPU cores, some of which might be on a different die. In the context of this patent, “mGPU”’refers to a GPU core (smallest replicable GPU device on Apple hardware), not a PCIe GPU board.
I think people fastened on "Logical Slot To Hardware Slot Mapping For Graphics Processors." and reading that the Hardware Slot is an expansion slot.
However a quick read (most of it over my head) then appears to be a way of prioritizing GPU work with references to High Priority Kickslots and Low Priority KickSlots and allocating GPU Cores to the Task
Where can kind of stack the work for the GPU putting it into a logical placeholder till actual hardware time becomes available to perform the work. That time being the hardware slot.
If have completely misunderstood then please let me know.
I think you got the summary pretty much correct. As far as I remember (it was a while ago that I read these patents), they also mention things like trying to schedule work that accesses the same memory regions on cores that share L2 cache and dynamically new work spawned by compute shaders (e.g. mesh shading) etc. "Kickslots" seem to simply refer to slots in a work table/queue, and the patents are about assigning work from this queue to actual hardware cores (e.g. each Apple GPU core contains four execution units and probably two or four schedulers).
These patents can be tremendously difficult to read and one really needs to take a lot of care trying to interpret them. I certainly cannot claim to fully understand what is going on there. I believe that @Dt990 is a passionate and intelligent person who is genuinely interested in the topic, but he seemed to rush a bit into all this without first establishing a solid knowledge base, and unfortunately created some unhealthy sensationalism in the process.
Another interesting question would be whether these patents refer to some upcoming technology or whether they have already been implemented. M2 Pro/Max/Ultra show some impressive improvements in shader utilisation in non-trivial workloads (such as Blender), so it is possible that we are seeing these patents in action. What's also interesting is that Apple describes groups of GPU cores that share L2 cache. As far as I am aware, we currently don't know how large these groups are, and I am not sure how to test it (especially since we don't have access to scheduling information from the shaders). It is possible that all GPU dies on one core share the L2 cache, but it's also possible that such group comprises 19 GPU cores on M2 Pro/Max dies (M2 Pro being a chopped down Max design). One thing that's fairly certain is that the two dies comprising a Max do not share the cache and need to communicate via the fabric.
Last edited: