AMD and Nvidia Will Make Arm-based Processors for PCs

[porina]

35 minutes ago, dizmo said:

I'm more interested to see what Intels response is. They must have some kind of plan, and if they don't it shows their inflexibility as a company which usually leads to failure. 

Back to my earlier post, what problem is the move to Arm supposed to solve? Going to Arm is only one potential path. Intel have a lot of process nodes on the near future as we come to the end of their catchup cycle. Intel 4 is in volume production now, as they build up stock for Meteor Lake. Intel 3, 20A, 18A are due to be ready by end of next year. Designs using it will lag process availability, but a market optimised x86 design on leading edge node might go against Arm.

 

Edit: while I might have focused on mobile use cases, that isn't the only one. Enterprise space already has Arm based offerings from players outside of consumer field. Nvidia already use Arm in their enterprise offerings. 

[Zodiark1593]

5 hours ago, wanderingfool2 said:

One other thing that it could end up doing though is better performance for certain tasks as well though.  So that might be a way into the market as well.

 

After all, the x86-64 is such a bloated set of instructions there is a ton of wasted space on the CPU die for essentially instructions that no one is realistically is going to use (except in a few edge case programs).  I think that's where MS will be able to just to x86 emulation, I'd imagine most wouldn't be too hard...just those programs that use that assembly would take massive performance hits.

 

Honestly though, the biggest win I could see for ARM, aside from making actual low powered CPUs that perform well is the ability to make one that's quite a bit more powerful for everyday kind of tasks (with exceptions for things like emulations which do require some of those x86 bloated instructions)

ISA doesn’t really matter anymore for efficiency, so much as the underlying architecture. Fact of the matter is that Apple is damn good at designing CPUs. ISA has little to do with it. 
 

https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/

[starsmine]

16 minutes ago, Zodiark1593 said:

ISA doesn’t really matter anymore for efficiency, so much as the underlying architecture. Fact of the matter is that Apple is damn good at designing CPUs. ISA has little to do with it. 
 

https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/

Honestly 80% of the power efficiency gains are the node advantage.

 

apple was mad at Intel not improving power yes… because Intel was stuck at 14nm for far longer then expected, not because of the ISA. Apple went arm because they don’t have an x86 license and can use the best nodes of tsmc and amd was not In a position to take on that contract 

[LAwLz]

12 hours ago, porina said:

Business reasons aside, the three points of the triangle are performance, price, power. Moving towards one area might compromise another.

Maybe you count this as a "business reason", but I would say a very big benefit of ARM is that it is not limited to just two companies.

Nvidia can't make x86 CPUs, so if they want to make processors they have to use ARM (if they want to support Windows). It wasn't a great situation we were in when AMD fell behind and Intel dramatically slowed down the rate of improvements they made year over year. If we had more competitors then chances are we wouldn't have seen such a slowdown in progress during those years.

 

It's good to have competition, and if arm takes off on Windows then we will get more competition.

[starsmine]

3 hours ago, LAwLz said:

Maybe you count this as a "business reason", but I would say a very big benefit of ARM is that it is not limited to just two companies.

Nvidia can't make x86 CPUs, so if they want to make processors they have to use ARM (if they want to support Windows). It wasn't a great situation we were in when AMD fell behind and Intel dramatically slowed down the rate of improvements they made year over year. If we had more competitors then chances are we wouldn't have seen such a slowdown in progress during those years.

 

It's good to have competition, and if arm takes off on Windows then we will get more competition.

I take umbrage at this characterization of the Skylake era of intel. 
We did not get a lack of improvement from intel BECAUSE of AMD not being there to push them. CPU architectures from white board to release takes 3-5 years from the start, assuming the node is where you want it to be. Key word is assuming that the node is where you want it to be.

Its not that intel didnt have competition on the architecture side or the node side. Its that their 10nm FAILED for multiple years due to over-ambition (it works now, and is called intel 7 as it was always closer to tsmc 7nm)

The entire tick-tock cycle was burned.
Broadwell, shrink of Haswell went, cool 14nm works.
Skylake, now the new archectecture on 14nm.
then... 10nm failed, no skylake shrink. put out a revised skylake on 14nm.
then 10nm failed,  no skylake shrink.  put out a revised skylake on 14nm.
then 10nm failed,  no skylake shrink.  put out a revised skylake on 14nm.

ok, new plan instead of shrinking skylake to 10nm.... ice lake which we finished can be a new arch on 10nm... it works... ish.
Back port it to 14nm for rocket lake. instead of shrinking it because intel 10nm still aint ready for prime time, and we can have something enticing for people. 
Tiger lake arch happened on 10nm(+)
then we got Alder lake on 10nm (intel 7, or 10nm++ as a joke)

its not that intel didnt want to put out new and faster hardware, its not that they didnt try because AMD wasn't pushing them. Its that they got LUCKY. If AMD bulldozer was worth a damn, Intel would have been absolutely fucked.

Journalists making the claim that Intel is back because AMD pushed them with competition, or that Skylake was stagnant because of the lack of competition from AMD, are taking the piss. No, no mater what AMD had done, intel would have made the SAME plays in terms of their fabs. 

This is why Apple pivoted. 

This is why intel is doing the 4 nodes in 3 year plan now because its not like development for those were fully stopped by the 10nm fiasco, just delayed and worked on in parallel by a much smaller team as people got moved over to 10nm (intel 7) to get it working. 

 

with MTL on intel 4 for desktop cancled, we should get Arrow lake as the next desktop chip in a year on intel 20A 


TL:DR Kaby lake through Comet lake was not Intels intention, but back up plans B, C, D, E, and F to just try to stay relevant to their customers after Plan A fell through year after year. Not because they were holding back due to AMD not being in the picture. The lack of competition had very little to do with their slowdown.

[igormp]

I have a slightly impression that this may not be desktop-focused, but rather only meant for servers, even tho the rumours say otherwise.

 

Anyhow, let's wait and see, it'd be nice it AMD brought back project skybridge.

[leadeater]

5 hours ago, starsmine said:

Honestly 80% of the power efficiency gains are the node advantage.

 

apple was mad at Intel not improving power yes… because Intel was stuck at 14nm for far longer then expected, not because of the ISA. Apple went arm because they don’t have an x86 license and can use the best nodes of tsmc and amd was not In a position to take on that contract 

And Intel nodes were optimized for desktop and server use cases rather than low power. Sure while Intel was riding their 14nm for ages it wasn't like anyone was actually beating them on actual CPU/product performance, not for a very long time.

 

5 hours ago, Zodiark1593 said:

ISA doesn’t really matter anymore for efficiency, so much as the underlying architecture. Fact of the matter is that Apple is damn good at designing CPUs. ISA has little to do with it. 
 

https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/

That's the exact article I was thinking of thanks

[leadeater]

4 hours ago, LAwLz said:

Maybe you count this as a "business reason", but I would say a very big benefit of ARM is that it is not limited to just two companies.

That's nice and all but this won't actually stop the problem of just a few big companies being the mainstay i.e. silicon fabs. Anyone can be a silicon fab however the actual number of leading edge ones is exceedingly small. I actually don't see it being much different, we'll probably just end up with a few clear pack leaders that will dominate giving us a situation not really any better. Maybe we will go from 2 companies to 3 or 4 but it's also likely 1 or 2 will only be relevant to consumers each product generation as the lead in XYZ of consumer importance changes between companies.

 

And the other fact is very few, just Apple?, actually make their own full designs and the rest are direct implementation of ARM designs so I don't see how 1, 2 or 10 companies making the exact same microarchitectures all on TSMC for example is going to help anything. That's like going to the supermarket and saying you have "brand choice" when the reality is it's all made in the same factory with the same ingredients and recipe and only the brand label put on it is different. A bag of frozen peas all source from the same suppliers so yay choice  heh.

[2dfx]

Interesting play considering that AMD's RTG is an absolute dumpster fire right now. 

[wanderingfool2]

14 hours ago, leadeater said:

Eh not really, can't remember which person in the industry commented on this but they said all the redundant not used instructions take up next to nothing which is also why they don't get taken out. If they really did they'd have a direct attributable cost to Intel/AMD in silicon fabrication and would get axed real fast.

Maybe not specifically tons of space in terms of the that...but the added instruction sets has a trick-down effect in regards to how everything gets managed.  Most articles I have found talk about it purely in terms of end performance on specific instructions but overall I think there is something to be said about the design around the architecture and how a bulkier instruction set can change how some things might have to get designed

 

Branch prediction for example; it needs to take into account the different instruction sets, so the more you have the more complex the other components become in it.  Zenbleed being a candidate for that, as it was failure to clean up the registers (iirc it was the ymm registers that weren't cleaned up after one of the AVX instructions or something similar to that).

 

Not saying that ARM automatically is less complex everywhere, just that there is a lot more to deal with in something such as x86.  They also can't just remove some of the features, unless if it was option instructions, as it would break compatibility.

[porina]

12 hours ago, LAwLz said:

Maybe you count this as a "business reason", but I would say a very big benefit of ARM is that it is not limited to just two companies.

Nvidia can't make x86 CPUs, so if they want to make processors they have to use ARM (if they want to support Windows).

Yes, business reason. It's not a technical one. Both are valid and need to be considered, but I was more focused on the tech in my earlier response.

 

Nvidia have their Grace server CPU using Arm, so for sure they're playing in that area. I'm sure they could get into x86 if they wanted to, but it likely isn't economic to do so for the business they're in. What advantage would it serve for the cost?

 

12 hours ago, LAwLz said:

It wasn't a great situation we were in when AMD fell behind and Intel dramatically slowed down the rate of improvements they made year over year. If we had more competitors then chances are we wouldn't have seen such a slowdown in progress during those years.

I see Starsmine covered it well already. It wasn't Intel didn't want to release better designs, they simply couldn't. AMD were fortunate in that as it gave them time to kick the ball rolling on Ryzen. Even then, it was only with Zen 2 they clearly passed Skylake in microarchitecture. Today there is very little to choose between them on performance, with AMD having a power advantage.

[leadeater]

4 hours ago, wanderingfool2 said:

Maybe not specifically tons of space in terms of the that...but the added instruction sets has a trick-down effect in regards to how everything gets managed.  Most articles I have found talk about it purely in terms of end performance on specific instructions but overall I think there is something to be said about the design around the architecture and how a bulkier instruction set can change how some things might have to get designed

 

Branch prediction for example; it needs to take into account the different instruction sets, so the more you have the more complex the other components become in it.  Zenbleed being a candidate for that, as it was failure to clean up the registers (iirc it was the ymm registers that weren't cleaned up after one of the AVX instructions or something similar to that).

 

Not saying that ARM automatically is less complex everywhere, just that there is a lot more to deal with in something such as x86.  They also can't just remove some of the features, unless if it was option instructions, as it would break compatibility.

I'm not sure it will have much effect on branch prediction as that is after decoding and is for the micro-ops, so any larger x86 instruction can be decoded down to micro-ops that are used for other x86 instructions. ARM has branch predictors too, since again it's a micro-op thing not a macro-op.

 

Not that I disagree there are flow on effects but the biggest thing by far is that any x86 ISA compliant CPU has to have 16bit, 32bit and 64bit operating modes and everything else that supports that, which is why x86-S will have some actual benefit as the entire hardware structure is built around 64bit native only with the capability to stuff 32bit operations inside 64bit processed as 64bit. That means absolutely all 16bit and 32bit x86 instructions will get axed and that's A LOT.

 

But also remember that ARM has lots of fixed function instructions now too, it is absolutely by no means light weight and "efficient" anymore compared to x86, it's another bloated ISA with lot of stuff added over time and remember at the time things get added they do/did have a reason to be. Which also means ARM CPUs have decoders too.

 

Quote

ARM Ltd’s own designs are evidence of this. High performance ARM chips have adopted micro-op caches to skip instruction decoding, just like x86 CPUs. In 2019, the Cortex-A77 introduced a 1.5k entry op cache[3]. Designing an op cache isn’t an easy task – ARM’s team debugged their op cache design over at least six months. Clearly, ARM decode is difficult enough to justify spending significant engineering resources to skip decode whenever possible. The Cortex-A78, A710, X1, and X2 also feature op caches, showing the success of that approach over brute-force decode.

 

Quote

Just like x86 CPUs, ARM cores are using op caches to reduce decode cost. ARM’s “decode advantage” doesn’t matter enough to let ARM avoid op caches. And op caches will reduce decoder usage, making decode power matter even less.

 

Simply ARM gets talked about and presented in the most not to real world way, even in industry, and the truth is x86 vs ARM is entirely irrelevant other than patents and licensing.

[LAwLz]

12 hours ago, starsmine said:

 

-snip-

The slowdown of progress happened before Intel started having trouble with their nodes, and even with the trouble they still made bigger strides than they did before once they got serious competition from AMD. 

 

If you want examples, look at Sandy Bridge -> Broadwell. 

That comparison includes both several micro architecture changes and node shrinks. Yet the different was very small. 

 

I get the impression that some people in this thread puts too much emphasis on manufacturing node and not enough focus on the micro architectures or chip designs themselves. Those matters a ton too. Not all processors made on let's say TSMC's N5 performs the same or have the same characteristics. 

[starsmine]

4 hours ago, LAwLz said:

The slowdown of progress happened before Intel started having trouble with their nodes, and even with the trouble they still made bigger strides than they did before once they got serious competition from AMD. 

 

If you want examples, look at Sandy Bridge -> Broadwell. 

That comparison includes both several micro architecture changes and node shrinks. Yet the different was very small. 

 

I get the impression that some people in this thread puts too much emphasis on manufacturing node and not enough focus on the micro architectures or chip designs themselves. Those matters a ton too. Not all processors made on let's say TSMC's N5 performs the same or have the same characteristics. 

Sandy to Broadwell had no slowdown

Sandy to die shrink Ivy
new arch Haswell to die shrink Broadwell

Ivy and Broadwell had negligible IPC improvements as they were shrinks. 

No, not all processors on N5 perform the same. that wasnt the point. However, outside of doing something obviously stupid with design, in terms of power efficiency gains, the vast majority of it is from the node. Yes you can always make it better on a node, but what you can do is tightly constrained. Neither AMD, Intel, nor Nvidia are generally releasing products that are not already near maxing out a node for efficiency. 

[porina]

5 hours ago, LAwLz said:

If you want examples, look at Sandy Bridge -> Broadwell. 

That comparison includes both several micro architecture changes and node shrinks. Yet the different was very small. 

Architecture updates typically give the biggest peak IPC uplifts.

 

My personal favourite Prime95 saw significant uplifts in the "Core i" era. 

Nehalem > Sandy Bridge was about 2x IPC due to addition of AVX

Sandy > Haswell was about 1.5X IPC due to updating to AVX2

Haswell > Skylake was +14% IPC due to general improvements.

Skylake > Rocket was about +40% IPC due to consumer AVX-512

Skylake > Skylake-X was about +80% IPC due to full fat AVX-512

Alder Lake would be a regression in IPC since they lost AVX-512 but I don't have numbers on that

 

If anyone wonders where AMD fits in, Zen and Zen+ were comparable to Sandy Bridge. Zen 2 is about +4% over Skylake. Zen 3 is about +10% over Zen 2. Zen 4 fits somewhere between Rocket Lake and Skylake-X but I don't have first hand data to be more exact. 

 

Don't like Prime95, how about Cinebench R15. It's an older version not using AVX at all.

Sandy > Haswell was about +16% IPC

Haswell > Skylake was about +12% IPC

 

[hishnash]

On 10/29/2023 at 1:27 AM, leadeater said:

Apple's biggest benefit is consistency, there is only 1 of XYZ product (our one), which I think matters a lot for the final products.

 

P.S Add in a dGPU and you can kiss power efficiency goodbye.

For sure, but this is also goes begone the extra bits but includes the SOC..

 

for example if your playing back a YT video basically the entier CPU will be powered down 99% of the time, the display controler is so large on die due to it having a good amount of local memory that it uses so that it can deliver frames without needing to wake up the rest of the system for each display refresh, and it does final composting (including color etc). 

 

On 10/29/2023 at 12:47 AM, porina said:

It will be interesting to see what Meteor Lake does, as it seems to be preparing in that direction. From memory the SoC tile has two E-cores and media processing, so you don't need to fire up the core tile for light tasks or near idle operation.

Most modern SOCs can fully power down separate parts within the same chip you do not need to break out tiles of this.  I expect the reason intel will go with a separate Tiel is node shink... cache is no shinking with node size any more so using a smaller (most expansive) node does not let you get more cache per mm2, I expect all vendors will be moving to seperate dies for cache..  looking at how intel binned 13th gen dies it also looks like they have some yield issues with e-cores so keeping them on the larger node might also make sense from a yield perspective if thinking them further is also an issue. 

[hishnash]

8 hours ago, leadeater said:

Not that I disagree there are flow on effects but the biggest thing by far is that any x86 ISA compliant CPU has to have 16bit, 32bit and 64bit operating modes and everything else that supports that, which is why x86-S will have some actual benefit as the entire hardware structure is built around 64bit native only with the capability to stuff 32bit operations inside 64bit processed as 64bit. That means absolutely all 16bit and 32bit x86 instructions will get axed and that's A LOT.

 

The `stupid` amount of legacy modes that (people) seem to expect of modern x86 chips must make the decode and the general development a lot harder than just building a 64bit only ARM v8.4 chip.   And the fact the applications are expected to be able to toggle from 64 to 32 and back again (not sure if you can toolset to 16bit mode but I would not be surprised if you first go to 32 and then toggle to 16)...

 x86-S will still have the full user-space 32bit mode so it does not complete solve this issue, your still looking at mode switching etc, just removes the need to support 16bit and 32bit in UEFI and lower level system management modes (why this was ever supported I don't know). 

[AndreiArgeanu]

In the light of the new snapdragon chip I can definitely see why. NVIDIA has been making arm processors for quite a long while as it is and they still are, AMD has dipped their toes before in Arm with their Opteron A1100 back in 2016. It will be interesting to see what comes of this and it does also make me wonder if we'll see these chips in consoles too when the next gen comes around.

 

Obviously breaking into the Desktop market is a really difficult task, mainly because of Windows. Arm compatibility hasn't been good, partly because Microsoft didn't put enough focus and effort into it and partly because backwards compatibility is still a really important part of Windows. It's why it was easier for Apple to switch to Arm, backwards compatibility wasn't ever really a selling point of Macs or their operating systems.

 

I've looked recently at a video from Jeff Geerling using a 128 core Ampere Altra arm chip and it was painfully obvious Windows is not ready for Arm but Linux is doing much better. NVIDIA doesn't even provide Arm drivers for Windows, only Linux so you can't even get a GPU working.

[hishnash]

13 minutes ago, AndreiArgeanu said:

NVIDIA doesn't even provide Arm drivers for Windows

There are currently no OEMs selling ARM windows systems with SOCs that support the needed PCIe spec for PCIe attached GPUs. 

[AndreiArgeanu]

4 minutes ago, hishnash said:

There are currently no OEMs selling ARM windows systems with SOCs that support the needed PCIe spec for PCIe attached GPUs. 

What exactly are you trying to say. There are Altra dev kits with PCIE lanes that support the spec and work with GPU acceleration under Linux. What spec does the specified system not support that specifically doesn't allow a GPU to work under Windows but allows it to work under Linux?

[porina]

41 minutes ago, hishnash said:

I expect the reason intel will go with a separate Tiel is node shink... cache is no shinking with node size any more so using a smaller (most expansive) node does not let you get more cache per mm2, I expect all vendors will be moving to seperate dies for cache.

There seems to be substantial cache on the core tile though. 2MB L2 and 3MB L3 per core. This compares with Zen 4 at 1MB L2 and 4MB L3 in the maximum core configuration. Looking again at Meteor Lake, it did remind me of something I forgot. The SOC tile E-cores are Low Power variations. Same architecture as other E-cores in the CPU but optimised for lower power running.

 

Moving caches off compute die, the question for me is at what level? Connectivity vs performance will be a tradeoff. 3D cache is already as good as it gets operating at L3. If Intel don't similarly go vertical, an edge connected implementation might be better suited as a return to L4. I'd love to see a modern implementation of L4 as it would likely be unified, unlike AMD's L3 in multiple CCD implementations.

[hishnash]

1 hour ago, AndreiArgeanu said:

What spec does the specified system not support that specifically doesn't allow a GPU to work under Windows but allows it to work under Linux?

The fact that no-one building that system is interested in running windows on it. 

 

 

1 hour ago, porina said:

The SOC tile E-cores are Low Power variations. Same architecture as other E-cores in the CPU but optimised for lower power running.

It is true they could be using a differnt process node (does intel even have low power optimised nodes like TSMC or maybe they are fabbing this on TSMC?) 

 

 

1 hour ago, porina said:

an edge connected implementation might be better suited as a return to L4. I'd love to see a modern implementation of L4 as it would likely be unified, unlike AMD's L3 in multiple CCD implementations.

They are sort of doing L4 in the data centre HPC system with HBM no? 

[porina]

28 minutes ago, hishnash said:

It is true they could be using a differnt process node (does intel even have low power optimised nodes like TSMC or maybe they are fabbing this on TSMC?) 

It's been public for a while. SOC+IO are on N6, cores are on Intel 4, GPU N5.

 

28 minutes ago, hishnash said:

They are sort of doing L4 in the data centre HPC system with HBM no? 

Like most of us here it's consumer attainable stuff that is of most interest. Recent HEDT/WS is already a big stretch, HPC is a dream.

[leadeater]

2 hours ago, hishnash said:

x86-S will still have the full user-space 32bit mode so it does not complete solve this issue, your still looking at mode switching etc, just removes the need to support 16bit and 32bit in UEFI and lower level system management modes (why this was ever supported I don't know). 

It does help a lot, IA32e mode (which is how things work now in 64bit OS's) isn't that much of a problem compared to having to support actual CPU hardware modes of 16bit and 32bit while 16bit is still used to make x86 computers boot and work at all, that needs to go away.

 

Have a look at the bigger doc from Intel https://cdrdv2.intel.com/v1/dl/getContent/776648, the changes are a lot. Also all current 64bit operating systems will not boot on a x86-S CPU either, will only work virtualized. 

 

Also as per my other comments in this topic about ISA's moving to x86-S won't give us any gains in performance or power efficiency, maybe performance a little but I doubt it. The biggest thing is freeing up space for more useful instructions we might want to add and cleaning up all hardware paths that related to 16bit and 32bit but I couldn't even begin to guess at any kinds of die area savings for that, absolutely no idea at all.

 

The whole point is mostly around simplifying design and validation, that's actually it. Anything else is just tangential benefits. 

[leadeater]

1 hour ago, porina said:

Moving caches off compute die, the question for me is at what level? Connectivity vs performance will be a tradeoff. 3D cache is already as good as it gets operating at L3. If Intel don't similarly go vertical, an edge connected implementation might be better suited as a return to L4.

If we are talking about moving things like L2 cache to a different die it'll have to be stacked, distance matters for L2. I don't see L1 moving though. The better thing would be hybrid and just have a very small amount of L2 on the compute die and then stack L2 and L3 above it.

 

45 minutes ago, hishnash said:

It is true they could be using a differnt process node (does intel even have low power optimised nodes like TSMC or maybe they are fabbing this on TSMC?)

Sort of, Meteor Lake has E Cores in two different tiles, one of them is TSMC, the SoC tile.

 

Quote

The compute tile is the first client-focused tile to be built on the Intel 4 process technology. It houses the latest-generation P-cores and E-cores, both of which are based on newer and updated architectures. The P-Cores are officially called Redwood Cove, while the E-Cores are Crestmont.

https://www.anandtech.com/show/20046/intel-unveils-meteor-lake-architecture-intel-4-heralds-the-disaggregated-future-of-mobile-cpus/2

 

Quote

The SoC tile itself isn't built on Intel 4 like the compute tile but is made by TSMC on their N6 node

 

Quote

While both the E and LP E-cores are based on the same Crestmont microarchitecture, the E-cores on the compute tile are built on Intel 4, along with the P-cores. The LP E-cores are made on TSMC's N6 node, like the rest of the SoC tile. These low-power island E-cores are tuned for finer-grained voltage control through an integrated Digital Linear Voltage Regulator (DLVR), and they also have a lower voltage-to-frequency (V/F) curve than the big E-cores on the compute tile, meaning they can operate with a lower power cost, thus saving power when transitioning low-intensity workloads off of the compute tile and onto the LP E-cores.

https://www.anandtech.com/show/20046/intel-unveils-meteor-lake-architecture-intel-4-heralds-the-disaggregated-future-of-mobile-cpus/3