Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Stratus Fear

macrumors 6502a
Jan 21, 2008
696
433
Atlanta, GA
Jim is no forefather of Apple Sillicon, he left in 2012. The only remotely close AS chip to M1 is the A12X/Z and that came out in 2018. 6 years later Jim left.

The newest design he may have even seen initial planning stages of would probably have been A8 or A9. Long before M1 was a twinkle in our eyes.
 

Sydde

macrumors 68030
Aug 17, 2009
2,563
7,061
IOKWARDI
Jim is no forefather of Apple Sillicon, he left in 2012. The only remotely close AS chip to M1 is the A12X/Z …
About 14 months after he left, Apple started shipping the A7 hardware. That was the initial AArch64 device, which they surely spent a year or more working on. Hence, one might say he had a pinky in AS, by having a tiny bit of involvement with the first 64-bit cores.
 

cmaier

Suspended
Jul 25, 2007
25,405
33,474
California
About 14 months after he left, Apple started shipping the A7 hardware. That was the initial AArch64 device, which they surely spent a year or more working on. Hence, one might say he had a pinky in AS, by having a tiny bit of involvement with the first 64-bit cores.

That’s assuming he had any involvement with A7. Apple does more than one thing at a time, and it’s not clear to me what he was really doing there.
 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,866
That really depends on the given function. Yes, if a Harvard architecture is not the best tool for the job, an FPGA can be faster. But, then, you could just make an ASIC that does the job that other way, and it would blow an FPGA out of the water.

Take something as simple as a 64 bit multiply. You aren’t going to do that faster on an FPGA than on an ASIC.
I am a professional FPGA wrangler and would like to put some extra emphasis on this by giving it a number, since I know exactly where to look that number up.

In Xilinx UltraScale+ (a fairly modern family -- all their newer stuff focuses on ML accelerators), the very fastest speed grade chips can run their DSP48 blocks (27x18 multiplier with a 48-bit accumulator) no faster than 891 MHz.

That might be more of a theoretical figure than a practical one, too. Thinking about trying to design for that speed makes me cringe. The DSP48 cells would be fine, Xilinx isn't lying, but it's the everything else feeding the DSP48s which becomes your waking nightmare. 500+ MHz in reprogrammable logic is not fun.

(You can eke a lot more out of FPGAs by doing things analogous to full custom design in ASIC, but it's a giant pain. The tools always fight you.)
 
  • Like
Reactions: joeblough

crazy dave

macrumors 65816
Sep 9, 2010
1,453
1,229
From Keller's Anandtech interview, it seems like he was there for the start as he talks about the team that design the first custom core(s) being about 150 people and the bones of the first generation of "big" chips that Apple designed. He also made it pretty clear is his recent roles including at Apple and especially AMD/Intel have been much more in the line of management than engineering - building and managing the teams, getting people motivated, and setting overall goals of the project.

He definitely stressed that having the right team is more important than someone like himself being a rockstar CPU designer or something like that. I believe @cmaier has placed similar emphasis that for CPU design it is more important to have a really strong team built than catering to the design whims of any one individual, talented as they may be. It's just too big for one person to be the be all and end all of it.
 

Fomalhaut

macrumors 68000
Oct 6, 2020
1,993
1,724
There are already macOS computers using alder lake processors :
www.hackintoshworld.eu
So I think that apple release their old intel machines soon.
I'd be a bit wary of a company supporting Macs that can't even spell "Apple"....
1644496612246.png


...and as for Apple releasing a new machine with an Intel CPU...

1644496694215.jpeg
 
  • Like
Reactions: JMacHack

JMacHack

Suspended
Mar 16, 2017
1,965
2,424
So the argument has moved to: without Jim Keller, Apple Silicon bad?

Actually just scratch that, the argument has always been “Apple Silicon bad” without substantiation.
 

mi7chy

macrumors G4
Oct 24, 2014
10,625
11,296
Argument is currently on building x64 hackintosh. From our exercise, M1 isn't fast enough to emulate x64 with UTM so it'll be interesting to see how well ARM emulation runs on x64 with QEMU which is what UTM is based on.
 

deconstruct60

macrumors G5
Mar 10, 2009
12,493
4,053
...and as for Apple releasing a new machine with an Intel CPU...

View attachment 1956911

another laptop , mini , iMac ... probably they are done.
It is still unclear if Apple is going to abandon the classic Mac Pro concepts and shift to something new or they they need another stopgap for a 1-3 year time period.

The issue is as the unit volume goes an order of magnitudes lower whether Apple is going to put effort into doing something for that segment. The high volume part of their line up there are economies of scale to trade-off being off the mainstream path.

Apple has said on multiple times where they think they can do a better job at something then that is a candidate for them to replace it with their own creation. (**) They taken their laptop optimized SoCs and put them into desktops. That may or may not work at the highest end of the desktop spectrum. low and mid range. Yes it has worked and Apple has mostly done it ( large screen iMac probably will largely go M1 Pro/Max from the MBP 16" ).

But can they go laptop design metric SoCs up the whole scale giving up Max RAM capacity , Max general purpose I/O , and max modularity? In 2011-12, Apple was distraction with doing lots of changes in other parts of the Mac line and pushed out of "warmed over" Mac Pro and tried to spin it as 'new' enough to give them another year or so come up with something else.
[ Apple shipped an "Ice Lake" era mobile processor in the MBP 13" four port for over a year. AMD is about to do a RNDA2 'refresh'. There isn't a bunch of new ground they'd have to cover they already aren't signed up for with macOS upgrades multiple years into the future. The decade track record of the Mac Pro and iMac Pro from 2012-2022 is not demonstrative of rapid evolution at Apple. It isn't a high priority target market for them for large R&D expenditure. ]

Pandemic hiccups pretty easily could have pushed something from a end of 2021 release window into 1H 2022 if it was a low priority project. That is far from being very highly probable, but also not quite in the "pigs fly" low probability zone either.

Apple could get up and do round 2 on their "can't innovate my ass" speech and totally move to the goal posts as to what is a Mac Pro. That would unnecessarily burn many bridges with a substantive number of deep pocketed customers.


(**)
P.S. 2022 iPhones are quite likely going to come with Qualcomm radios. Apple bought Intel's modem business in late 2019 (completed ). Apple isn't using their own radio's because for the moment Qualcomm's are very likely better for the specific purposes for the last two years of phones and next year also.

Where Apple has not been (e.g., radios or upper 10% workstation and servers ) they are not necessarily going to move very fast to replace with something not primarily aimed at those markets.
 
Last edited:

mi7chy

macrumors G4
Oct 24, 2014
10,625
11,296
From a business point of view it does make sense for Apple to consolidate products running on iPhone/iPad SoC since they sell very few x64 devices relative to ARM. For the small number of specialized customers that require x64 just go Hackintosh then when Apple EOL x64 MacOS the transition to another unix OS like Linux will be easy plus that's the preferred OS for machine learning dependencies and tools.
 

JMacHack

Suspended
Mar 16, 2017
1,965
2,424
Argument is currently on building x64 hackintosh. From our exercise, M1 isn't fast enough to emulate x64 with UTM so it'll be interesting to see how well ARM emulation runs on x64 with QEMU which is what UTM is based on.
From a business point of view it does make sense for Apple to consolidate products running on iPhone/iPad SoC since they sell very few x64 devices relative to ARM. For the small number of specialized customers that require x64 just go Hackintosh then when Apple EOL x64 MacOS the transition to another unix OS like Linux will be easy plus that's the preferred OS for machine learning dependencies and tools.
?
 

deconstruct60

macrumors G5
Mar 10, 2009
12,493
4,053
From a business point of view it does make sense for Apple to consolidate products running on iPhone/iPad SoC since they sell very few x64 devices relative to ARM. For the small number of specialized customers that require x64 just go Hackintosh then when Apple EOL x64 MacOS the transition to another unix OS like Linux will be easy plus that's the preferred OS for machine learning dependencies and tools.

Hackintosh will likely significantly 'die' before macOS on Intel gets to EOL. Once get to the point where all non Vintage macs are T2 macs then probably can end the boot sequencing for the old more open EFi/UEFI boot process. (i.e., get to some point there all still supported mac have an Apple slicon chip controlling the boot process) Apple is doubtfully going to be tolerant of hackintosh as the number of active Intel Macs shrink. Hackintosh never paid for upgrades (which is what happens when you buy a Mac). Those systems will just be leeching off of a shrinking pile of pre-paid upgrade funds. That is fine when hakintosh is some very low percentage of active systems and there is tons of new upgrade funding inflow. A 1-4% 'theft' rate can be just assigned to "cost of doing business". Over time that percentage likely will raise up into the "annoying and loosing us money" zone.

macOS is also going to flush kernel extensions over time. Apple expliciltly announced this a couple of years ago. Those too will probably get nuked by the time supported Macs get into the T2 only zone ( if not sooner). Drivers in x86 for future common PC components are going to dry up also. [ as target market shrinks new driver R&D funding allocation will shrink also. M-series will get new era drivers because that market is growing; not shrinking. ]. "But M1 macs allow an optional kernel extension mode"... yeah and some early transition Intel Macs had 32 bit EFI.... that isn't where Apple is going long term. They have already stated it and put folks on a countdown clock to "fix that". ]

Similar OpenGL and OpenCL ... again probably sacrificed on the alter of Metal only future before macOS on Intel gets fully decommissioned. ( Pretty good chance Metal becomes more and more Apple Silicon proprietary over time. And if there are no new 3rd party GPU opportunities the 3rd party makers are going to be less and lesss interested in supporting a "wide GPU interface" stack . Apple isn't for sure (since put these two on the deprecated list). )


IMHO, Apple is unlikely to prematurely kill off macOS on Intel ( a good minimal 5-6 year horizon going forward ... the delay of the large screen iMac coupled to the top Mini is kicking that can forward.) , but pretty decent chance they will "boil the frog" slowly to prune off the folks who are just want to sit on "old as possible" apps and not follow where they are going with the Mac evolution. That "slow boil" will probably cause Hackintosh problems. ( where "hackintosh" will shift over to be old Macs run in ways Apple doesn't approve and then stop. And a smaller few that to pile increasingly complicated hacks to "prove" it can still be done with enough bailing wire and duct tape in Rube Goldberg style. )


the transition to another unix OS like Linux will be easy plus that's the preferred OS for machine learning dependencies and tools.

Windows Subsystem for Linux (WSL) isn't trying to de-integrate perl, python , etc. Competitor OS options aren't in some long far off distant future. WSL is not stuck to x86 only.

Linux already is the prefferred OS for ML toolchains. That isn't really a 'future tense' thing. If Apple goes hostile to multiple full bandwidth PCI-e v5(6) x16 add-in cards internal provisioning, then that is just even more entrenched. Apple is already behind the curve there and it will only get worse.
 

mi7chy

macrumors G4
Oct 24, 2014
10,625
11,296
Big question is, if Apple is retiring x64 MacOS then why did they add support for AMD RX6000 series dGPU that they don't currently offer in any product. That has to mean that they're either promoting Hackintosh or they're planning to continue x64 with RX6000 graphics.
 

joeblough

macrumors 6502a
Sep 30, 2006
619
439
That might be more of a theoretical figure than a practical one, too. Thinking about trying to design for that speed makes me cringe. The DSP48 cells would be fine, Xilinx isn't lying, but it's the everything else feeding the DSP48s which becomes your waking nightmare. 500+ MHz in reprogrammable logic is not fun.

true that. i was working on an FPGA prototype of an ASIC once and one of the other logic designers was strictly an ASIC guy. i was responsible for the top level and couldn't get timing closure on his code even at 133Mhz. not even close. when i talked to him about it he was like "oh you just need to buffer all those high-fanout nets" and i was like lol, this isn't a standard cell design man. it took repeated beatings to get him to pipeline his code.

at that time routing delays in FPGAs dominated everything and i'm sure that's still the case given the nature of the beast.

(You can eke a lot more out of FPGAs by doing things analogous to full custom design in ASIC, but it's a giant pain. The tools always fight you.)

way way back in the day i was working on an altera design back when (IIRC) the tools were called "maxplus2" and were really an offshoot of PLA compilers rather than something like synplify which was more coming at it like design compiler but for fpgas. i got into this situation where even though the utilization wasn't critically high the tool could just not come up with a valid P&R after fixing a very small bug and resynthesizing the whole design. i ended up having to edit the AHDL netlist to fix the bug and keep most of the original placement, iterating until it found a solution for the handful of new nets/flops. fun times.
 

cmaier

Suspended
Jul 25, 2007
25,405
33,474
California
true that. i was working on an FPGA prototype of an ASIC once and one of the other logic designers was strictly an ASIC guy. i was responsible for the top level and couldn't get timing closure on his code even at 133Mhz. not even close. when i talked to him about it he was like "oh you just need to buffer all those high-fanout nets" and i was like lol, this isn't a standard cell design man. it took repeated beatings to get him to pipeline his code.

at that time routing delays in FPGAs dominated everything and i'm sure that's still the case given the nature of the beast.



way way back in the day i was working on an altera design back when (IIRC) the tools were called "maxplus2" and were really an offshoot of PLA compilers rather than something like synplify which was more coming at it like design compiler but for fpgas. i got into this situation where even though the utilization wasn't critically high the tool could just not come up with a valid P&R after fixing a very small bug and resynthesizing the whole design. i ended up having to edit the AHDL netlist to fix the bug and keep most of the original placement, iterating until it found a solution for the handful of new nets/flops. fun times.

The good news is that in ASICs now, routing also dominates everything :)

You can fix slew rates with repeaters, but parasitic RC is still a pain in the ass. That was even the case back in the mid-1990’s - most of the time I spent on physical design was on manual placement, partial manual routing, shielding against coupling caps, etc.
 
  • Like
Reactions: joeblough

robco74

macrumors 6502a
Nov 22, 2020
509
944
Apple may support new Radeon cards because Mac Pro owners may want to install one. I imagine they will support new cards for a few years. It isn't to enable Hackintoshes, it's providing good product support for an expensive machine. They may have also been able to support the new card with only minor changes to the existing drivers.

The x64 version of macOS will be around for some time, as the PPC version was before, and the 68K version before that. They're still selling new Intel-based machines, they aren't going to cut support for those customers overnight.
 
  • Like
Reactions: huge_apple_fangirl

mi7chy

macrumors G4
Oct 24, 2014
10,625
11,296
Refresh my memory. When has Apple in the past sold Apple relabeled GPU upgrades for Macs? I just recall people buying 3rd party.
 

dgdosen

macrumors 68030
Dec 13, 2003
2,817
1,463
Seattle
Argument is currently on building x64 hackintosh. From our exercise, M1 isn't fast enough to emulate x64 with UTM so it'll be interesting to see how well ARM emulation runs on x64 with QEMU which is what UTM is based on.
I have a AMD 3900X/64GB hackintosh... it's great and all, but I can safely say I would gladly move from that to a M1 Pro/Max Mac mini... and that it'd be nuts to build a new one today.
 

mi7chy

macrumors G4
Oct 24, 2014
10,625
11,296
Guess "past" vs "current" is too confusing. What Apple labeled/relabeled GPU upgrades did Apple offer for Mac 2013, 2012, 2010? More likely the new RX6000 series driver support addition in MacOS is for upcoming Mac x64 refresh.

P in FPGA means programmable. What tools does Apple provide for the customer to reprogram the FPGA? The discussion was in context to on-chip FPGA coprocessor with CPU.
 

JimmyjamesEU

Suspended
Jun 28, 2018
397
426
Guess "past" vs "current" is too confusing. What Apple labeled/relabeled GPU upgrades did Apple offer for Mac 2013, 2012, 2010? More likely the new RX6000 series driver support addition in MacOS is for upcoming Mac x64 refresh.

P in FPGA means programmable. What tools does Apple provide for the customer to reprogram the FPGA? The discussion was in context to on-chip FPGA coprocessor with CPU.
Lol. Customers….reprogramming a fpga. Just give up dude. It’s ok to admit you don’t know what a fpga is.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.