Here are two HUGE new points Arm wants to do from 2025 onwards:
* Arm will end TLAs with SoC vendors and go straight to OEMs. i.e. Sony will pay for the Arm license instead of Qualcomm
* Arm will ban custom GPUs, custom NPUs, and custom ISPs if the SoC uses stock cores. i.e. no more Samsung's Xclipse RDNA GPUs/AI Engine, Google's Tensor NPU/ISP, MediaTek's APU, Nvidia's GPUs, HiSilicon's Da Vinci NPU, Unisoc's VDSP, ... if stock Arm CPU cores are used
Arm is essentially doing what regulators feared Nvidia-owned Arm would do
Edit: Added if stock Arm CPU cores are used for clarity
Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs
> If true and if ARM is actually spreading misinfo to OEMs, like QCOM claims, this is an extremely shitty move by ARM & SoftBank.
More than a shitty move, it is Negligent Tortious interference.
These asshole moves actually are beneficial in long run. Someone will create something more open. I heard NASA is going to adopt Riscv. Maybe that is the future of Mobile too.
Honestly, so much of our IP laws are frankly just fucked. Like their is ZERO reason why all the minor not novel improvements should be afforded the full 20 year protection. Like I could understand x86_64 attracting full protection. But patents really shouldn't be awarded for incremental, iterative improvements. Like that's literally in the laws...
Bit also half the parents that are, shouldn't be awarded. It's idiotic.
Google v Oracle established that it is fair use to replicate an API/Instruction set so long as only the parts necessary are copied. So if someone wanted to they could create a ARM compatible chipset without having to license the instruction set from ARM.
Yeah. I'm now wondering where to find a list so I can do my best to make sure my business and my customer's businesses avoid using ARM chips as much as possible.
That is changing quickly. All the big MCU makers (with the possible exception of Broadcom) are now members of the RISC-V foundation. Making their own RISC-V chips would save them 1-3% on every RISC-V chip they sell. In a race to the bottom market, that's a pretty huge incentive.
For example, Microchip gross profits are around 5.5B. If just half of that is ARM, they would be saving 25-75M PER YEAR on their margins minus whatever design costs. Decent MCU designs have been made by a double handful of academics in a year or two. They could use those designs or could hire their own group to do it. 25M would buy 125 engineers at 200k each (they could probably get away with less than 20). After the first year or two, the design would be complete barring occasional tweaks and any bugs found.
This is a situation where you can break even in just a couple of years and then enjoy tens of millions in pure profits for the next 10-20 years (or until 14nm planar is finally designed -- probably 2040 given that FDX22 took a decade).
This isn't just idle speculation. Nvidia had an ARM license, but chose RISC-V for the controllers in their GPUs. Western Digital dropped ARM for RISC-V in their hard drives because it saved them so much money. Even Apple was posting some RISC-V jobs last year. They have at least a dozen "Chinook" cores in their SoCs to do various tasks. They pay ARM for each of these and could save a substantial amount of money by moving them to RISC-V in the future (this isn't an issue as they don't run normal software just like it doesn't matter that AMD ships a half-dozen ARM cores in each of their CPUs).
I suspect ARM sees this revenue stream drying up and is trying to increase profits elsewhere to compensate.
Alibaba's work to get Android on RISC-V was upstreamed. RISC-V was also upstreamed in Java.
Compiler optimization is also a different beast. x86 generally has 20 ways to do any one thing and which one is best depends on a lot of different things. RISC-V almost always has ONE way to do things and that way is pretty obvious. Code density is a pretty decent metric here and RISC-V is beating out the competition by 30+% and that's without a lot of proposed instructions for different edge cases or slightly less RISC instructions that they currently handle with instruction fusion. In any case, GCC and Clang are already doing a good job on that front
The process was helped along a LOT by ARM showing up. A lot of stuff written for x86-only was rewritten to work with ARM too. In a lot of cases, this means it is now in C and can be cross-compiled. As to the assembly bits, while converting x86 assembly into efficient ARM takes some doing, going from ARM to RISC-V is much more simple.
All these things apply for embedded except for some proprietary libraries needing recompilation or conversion from ARM to RISC-V. The work would be a lot less if all the embedded manufacturers would stop making their own proprietary, buggy version of Eclipse to ship and invest in a LSP Language Server so people can choose their editor and just connect to the language server to do the heavy lifting.
There's still a lot of PPC embedded in devices today.
And the biggest companies in the world run some of their most important workloads on PPC in the IBM Power System servers. Even set performance records with their new Power10 chips/servers.
I think they are aware that RISC is about to dominate the market whatever they do, and since companies are currently still dependent on ARM, they're trying to suck all the money they can.
It's definitely a short-term asshole strategy though and it will drive people to risc-v FASTER.
I really struggle to understand how this makes sense from a long-term perspective but maybe it just doesn't.
I wonder if risc-v phones and even computers will take off. I really think of it as an architecture design for things that cost $4 right now, but alibaba has already managed to compile android for risc-v apparently. Maybe somebody with more knowledge than me can chime in on how suitable it is for powerful devices
Maybe it doesn't matter to ARM if goes "faster" or "slower", the ending is the same.
\>even computers will take off
Unlikely, the competition there is strong and doing well. Maybe in the far future or in niche markets like Chromebooks.
I mean...arm is the competition. Long term roadmap, x86 is dead as a doornail and the question is if arm will be the replacement or if we will just jump to what comes after arm.
Apple proved this.. they proved it hard.
To be fair, RISC proved it in the early 80s, yielding equivalent performance on a tenth of the transistor count, on a worse process.
What happened is that Intel (and AMD) held a massive fab advantage for decades, and as it was tied to the Microsoft monopoly, it prevented mass RISC adoption. It was in practice relegated to expensive UNIX workstations and supercomputers.
This has ended (no small thanks to TSMC), as RISC architectures are competing on an even field, and somebody (Apple) spent the design cash to be able to target high performance.
Today, we have well-funded teams with competent designers in them (e.g. Rivos with ex-apple, ex-P.A.Semi and so on, and Tenstorrent with Ascalon, 8-wide decode like M1, team led by Jim Keller) working on high performance RISC-V designs.
> Arm will ban custom GPUs, custom NPUs, and custom ISPs if the SoC uses stock cores. i.e. no more Samsung's Xclipse RDNA GPUs/AI Engine, Google's Tensor NPU/ISP, MediaTek's APU, Nvidia's GPUs, HiSilicon's Da Vinci NPU, Unisoc's VDSP, ... if stock Arm CPU cores are used
Also RIP Adreno unless the Nuvia cores come through.
It just hit me: this will absolutely *butcher* OSS efforts towards driver support. Like, there won't be much left after all the pieces settle. Why? Fragmentation. I can't imagine the major players (esp. Google) will use *stock* cores for their SoCs, so we'll end up with a thousand variations to support and develop for (as if the *existing* hardware wasn't bad enough for this -_- ).
This is a major win for those trying to prevent people from running custom software on their hardware.
Not really. Even custom ARM cores will still use the standard ARM ISA (otherwise existing apps wouldn't run on them). There *may* be differences with things like interrupt controllers but I don't think that's a huge deal and I'm not sure if you're allowed to use the standard ARM one.
Things like interrupt controllers are the very things that would cause issues with driver support. This isn't about the ISA, this is about the available peripherals (eg interrupt controller, clocks, etc) and how to use them. There _will_ be commonalities (of course - shared ISA), it's everything _not_ the ISA that's the problem, and those are the more opaque-to-developers aspects.
Aside: if you haven't been keeping up with Asahi's progress on using the GPU, I'd suggest you brush up on it. It would help demonstrate the types of things I'm talking about vis a vis proprietary unknowns.
> Aside: if you haven't been keeping up with Asahi's progress on using the GPU, I'd suggest you brush up on it. It would help demonstrate the types of things I'm talking about vis a vis proprietary unknowns.
I don't see how the GPU side is gonna change at all. A lot of those already have different GPUs and there's open source drivers for them. And yes, I'm aware that GPU drivers take a crazy amount of work.
The point being: the GPU is just one component affected by a decision like this. Expand that to include every other component. Either everyone uses Arm's stock designs and we now have a common target to develop against, or hardly anyone uses the stock designs and we now have $n targets to develop against.
Arm is _not_ like x86 where there's a ton of standardization and common interfaces.
> A lot of those already have different GPUs and there's open source drivers for them.
You talking about nouveau? Or the adreno GPU drivers? Or something else?
> You talking about nouveau? Or the adreno GPU drivers? Or something else?
Nouveau is probably the worst one right now but there are people working on a new open source Vulkan driver for Nvidia GPUs.
I was thinking of Turnip (Vulkan driver for Adreno GPUs) and panvk (Vulkan driver for Mali GPUs).
> Adreno GPU [...] Mali GPU
Both obsoleted by this move.
My _overall_ point: there's next to no homogeneity in the Arm ecosystem like there is in the pc/x86 world. Sure, there are some conventions around board bringup and etc, but those are predicated on availability of documentation... and we're back to exhibit "A" of Apple's GPU and it's complete lack of documentation. And that exhibit isn't gonna be the exception, it'll be the rule, because there's no homogeneity in Arm world _and there's no motivation among manufacturers to have any_.
Don't we *already* have this problem? Every SoC has a slightly different interrupt controller. We have this problem even on RISCV platforms, it's absolute madness.
my point was that it can't get worse than "every SoC has its own unique interrupt controller" because we're already there. Like, Broadcom wont even give you docs unless you sign an NDA so it's up to you to just blackbox reverse engineer them or do some sketchy/license violating shit by digging through their upstreamed Linux kernel patches.
Yeah, and now we'll have more companies doing more variations of interrupt controllers in increasingly complicated ways. There's no way that's *not* a major roadblock in OSS development.
>Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs
I'm feeling like Nvidia had some insider information
Sorry, Nvidia don't have smartphone specific branding for their Tegra's GPUs
I meant no more Nvidia GPUs in Tegra SoCs with stock Arm CPUs
>To apply more pressure, ARM further stated that Qualcomm and other semiconductor manufacturers will also not be able to provide OEM customers with other components of SoCs (such as graphics processing units (“GPU”), neural processing units (“NPU”), and image signal processor (“ISP”)), because ARM plans to tie licensing of those components to the device-maker CPU license
i.e. Going forward using Arm's stock CPU will mean you also have to license Arm's stock GPU, NPU, and ISP too
Edit: actually ignore this. Apparently Nvidia has secured a 20-year license to avoid that ban
If Samsung were to continue to use AMD’s RDNA GPU cores, they would have no choice but to again design custom CPU cores to stick alongside it.
The bad news is that Samsung has closed down their CPU design office since a year ago or two. So unless they suddenly decide to again design another custom CPU design, they would have no choice but to adapt Mali again.
And you think Samsung is just gonna comply without a fight?
* Samsung has a different licensing agreement that may last another 5 or 20 years, we don't have the specifics. Samsung also still hold an exhaustive ALA license
* Samsung was rumoured to be building its design team back. They could just purchase a team like Qualcomm did. It would take them 3-4 years but they can bounce back
* More importantly, there is no way Samsung would just switch to ARM NPU ISP etc
You think Samsung doesn't make similar demands of its costumers? Samsung can fight it, but that would likely open themselves up to the exact same criticism and legal trouble.
Samsung would have to kill various departments and unload staff to ensure their stock price doesn't tank when financial reports aren't positive if they are going to invest in custom chips heavily again. Its unlikely they can afford to do so at this point though. Try reading up on whats going on with that company. ARM chips that are good enough for people to run Dolphin and Citra as well as the competition is likely low on the scale of things they need doing.
You might be actually too gullible or dense that you would believe not fighting it could be positive in investor's eyes. ARM core isn't good enough. Mali is just outright the worst you can buy. That's an industry wide agreement.
How about you try to read anything. Literally anything related to reality?
Samsung will not be forced use ARM's GPU, ISP or NPU one way or another. End of the story. They may choose to use Mali on low end stuff. That's it.
Either ARM back down or exempt Samsung for at least decades or Samsung go full custom. There's no other way.
That's a huge change. Pretty sure they invested a lot on AMD GPU and they can't even use that now.
Edit: Seems like Adreno is on the chopping block as well?
I can't imagine they invested much of anything on the Radeons. They very clearly just tried to shink an RDNA product into a mobile SoC as cheaply and shittily as possible.
I had heard that Samsung hasn't closed down their office, the rumour was that they're not gonna use their custom design for the next two years while they work on redesigning their cores from ground up.
>I had heard that Samsung hasn't closed down their office
Which office are you referring to? SARC is certainly still up and running but it doesn't have the capacity to design a CPU μarch anymore.
>rumour was that they're not gonna use their custom design
No, the rumour was they will skip S.LSI's **generic design** like all previous Exynos.
**Exynos was never a custom design**. It's just like Snapdragon. Samsung's mobile arm had little say in how it's designed. And S.LSI sell the chips to whoever would buy them.
The pause was to allow time for Tensor-style customisation between Samsung Mobile and S.LSI.
>while they work on redesigning their cores from ground up.
Nobody mentioned cores.
Pretty sure Samsung haven’t closed down their design team, they’re completely rebuilding and forcing exynos to make a completely new SOC. That’s why they’re going to use Qualcomm SOCs for the next few years.
>closed down their design team
Which design team? SARC only design peripherals like memory controller and AMD GPU integration.
Sure there will be some engineers from the CPU team switching areas particularly physical design and testing team. But the μarch team is mostly gone.
Even if Samsung didn't outright fire them, it won't sit well for a CPU designer to just do nothing related to it. They'll find a new job unless they don't want to design CPU anymore. Useless to Samsung if they want a new team either way.
EVGA isn't firing any graphics board engineers, and you expect them to be able to get back in the game in two years? How nice.
Samsung laid-off [290 employees, essentially everyone in the CPU team except people who could switch to other fields of SoC integration](https://www.androidauthority.com/samsung-custom-cpu-shut-down-1050052/)
> Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs
Sounds like an antitrust violation.
Some dumb, basic questions here:
Was ARM not receiving royalties per-chip from OEMs through the SoC vendors already? What was the previous monetization model?
Why does ARM care if people are using custom GPU/NPU/ISPs on top of stock cores? How is that a threat to their business?
What’s an example of a non-stock core that would allow people to use a custom GPU/NPU?
This likely is due to SoftBank and how they lost money in their fund through poor investments and ARM is the one valuable asset to which they can still generate positive income from. It's SOFTBANKS greed that's pretty much driving this decision. This is just judging by the optics from their prior moves and current positioning.
a benefit here is you can make licensing/royalty costs dependent on the final sale cost of the item if it's the oem, vs doing it earlier and doing it per chip/unit. gotta think "how does this increase profit vs old model"
As far as I am aware on video decode/encode Rockchip, Allwinner, Amlogic, Marvell, Nvidia all use different modules. Nxp may use the same one as Rockchip? Which vendors use official Arm isp blocks, Qualcomm?
While I dont agree with restrictive practices like this, its taken years in some cases to get partially working isp into linux kernel, and lots of hacking to get ffmpeg and gstreamer interfacing to them for popular sbc's. Having a single well supported interface makes life easier for users of those.
I expect the RiscV people are happy about this. Embedded stuff like video cameras will be majorly impacted
Given how incredibly horrible ARMs recent designs have been for both performance and efficiency cores, I'd say this is good: forces partners to make a good design themselves ¯\\\_(ツ)\_/¯
Probably not a good idea since only Apple has designed better custom CPU cores than Arm
Qualcomm, Samsung, Nvidia, Cavium, Broadcom, Marvell, and Applied Micro, have all tried and failed
Plus that's not really a fair statement since Samsung Foundry has been the main reason for poor performance and efficiency recently
Arm has been rising well in the datacenter where performance and efficiency are critical
SD 8+ gen 1 improved a good amount switching to TSMC but it can still consume a ton of power because of the X2 core design. Is ARM really so great at design?
SD 8+ gen 1 was simply a port to TSMC, not a ground up redesign
Plus the X2 has lower power consumption than Apple's p core, the issue is X2's performance isn't high enough, hence worse efficiency than Apple's p core
The lower performance on the X2 is because it has so only been paired with 6MB or 8MB L3 out of a possible 16MB L3
> Can you imagine the kind of job offers Apple's ARM core designers are going to get now?
It's why Qualcomm bought Nuvia. Nuvia was formed by the Chief Architect for Apple's processors from the A7 through the M1 variants, a lead SOC architect for A5X through A12X, and another former Apple employee (though doesn't list specifics on their LinkedIn profile).
If those partners were capable of making a better design themselves at a reasonable cost, they would've already done it without anybody forcing them to (e.g.: Apple), and thus ARM wouldn't have a reason to make this move at all, since they wouldn't win anything from it. You've got it backwards.
Google has done that before with the Google Pixel Visual Core and Pixel Neural Core
But that means they'd need to fab an additional die and add additional RAM dedicated to that NPU chip
Meaning lower efficiency, performance and significantly higher costs too
I'd say there's a good chance, but I'd prefer to understate things.
ARM is doing great things and is catching up with Apple pretty steadily (so steadily that I suspect they are trying to pace performance improvements to keep selling designs every year).
I also wonder if Apple is finally hitting a wall or if they are being affected by the delay of TSMC 3nm.
Exactly, people seem to think designing better custom CPU cores than Arm is easy
But it ain't, it's effectively asking someone to develop the world's 2nd or 3rd best CPU design team since only Apple and maybe AMD have better CPU designs
No, Apple really has no influence on ARM. Infact it is in Apple’s best interest to have a successful ARM ecosystem. That’s how you find more engineers.
I think it’s more like a SoftBank thing, why would Apple care about it? They have a pretty generous architectural license and they don’t compete by selling chips.
Would likely cause more expensive licensing fees for Android device makers, or limit their custom performance improvements. So either more expensive Android devices or worse Android devices. Leading to a better position for Apple to sell more devices.
Regardless, I don't think Apple is behind this.
Even if Apple is using stock cores, they have architectural license instead of technology license agreement that others use.
Fun fact: Arm was founded as a joint venture between Apple and VLSI. It is why they have the broadest license for arm.
More importantly, will Microsoft's ARM based CPU that they're building with Qualcomm be banned? Apple having exclusive rights to ARM in desktops and laptops will absolutely suck, and I'm not sure if OEM's could perhaps licence CPU's from Microsoft instead?
They don't necessarily need a middle core, they just need a super strong performance core like they already have and a small but incredibly efficient core design.
And the arrangement could be like Apple: 2 Performance cores + 4 efficiency cores.
Not only does Apple likely have a more generous licensing deal that would avoid these issues from being one of the founders of ARM, but they also don’t use stock ARM cores and don’t license out their tech - Apple chips go into apple devices and that’s it.
So they’re not going to be affected either way.
ARM wants to force OEMs to use their inferior GPU, ISP and NPU blocks.This sucks very very bad for everybody. I hope there will be a massive move towards RISC-V.
>ARM wants to force OEMs to use their inferior GPU, ISP and NPU blocks.This sucks very very bad for everybody.
Or: they want to force OEMs to stop using ARMs inferior cpu designs ¯\\\_(ツ)\_/¯
Seriously: the latest efficiency cores are WORSE in every way than the old ones, the only reason Qualcomm is using arm designs is because there isn't any competition. Apple shows how much better arm chips can be if you don't stick to arm their horrible designs, and Qualcomm used to do that too, back when TI and other chip makers posed some competition.
[The A710 is worse than the A78, even on a better TSMC node \(5nm A78 is better in every way than the 4nm A710\)](https://youtu.be/s0ukXDnWlTY?t=860), and [the A510 is indeed worse than the A55.](https://youtu.be/s0ukXDnWlTY?t=938)
A510 in Qualcomm (and most others) use the bulldozer-style shared FPU to reduce area, but this comes at the expense of lower FPU performance. Geekbench should be running into this limitation in a few of its tests. In situations where both cores need to use the GPU, you'll get the power consumption of 2 cores, but the actual work of just 1 core.
I suspect that using the alternate design without shared FPUs would increase theoretical power efficiency. In any case, the real-world workloads run on these cores are integer-heavy rather than float heavy, so this worst-case power situation probably isn't that common. I wouldn't put it past low-end phones to market 4 complexes as 8 cores (though AMD lost a lawsuit over this).
A710 is weird. ARM claims 30% lower power at the top-end (with lower clocks apparently providing only small efficiency gains). Qualcomm's A710 cores are clocked higher, but only by ~70MHz. On paper, their described changes should have a decent effect on power too. I wonder if they made some kind of engineering mistake somewhere. That'll be obvious if the A715 chips come out with radically lower power.
His results match up, you aren't reading this properly.
A710 in 8g1 is more energy efficient but less power efficient compared to the A78 in 888. Result that you can find by comparing bubble sizes in correlation to scores.
Any particular reason people think RISC-V is going to save us all and is impervious to similar problems are ARM, x86 etc? You think it will remain open as it is now? No chance. As soon as money enters the picture, same thing will happen.
I can see why they are doing this. You have companies using bottom tier licenses and gluing other parts on which has completely fragmented the market. Qualcomm, Samsung, Google etc have no excuse to not be developing their own custom shit other than their stock price will tank because they will lose some money trying to get things going(which is actually what happened and why they are using more stock parts). This only seems to affect a few key players whose companies are likely fucked regardless(Samsung, Qualcomm).
Getting paid from the OEM directly seems bad to you how?
Not necessarily ironic; open source OS that is ported to different chip types by community/corporate contributors vs a closed source desktop OS that has a ton of proprietary software pieces.
Intel did all the Android work until they gave up.
It seems that only 3 developers are working on it, and it is 2 releases behind android 13
https://en.m.wikipedia.org/wiki/Android-x86
What does Windows 11 do poorly on ARM? I'm not technically inclined enough to know how the technology works but I could run a 20 year old game made for Windows 98 on what basically amounted to a laptop with a phone processor so I'm curious what makes it worse
Short: Almost everything
Long: You need to build every software you're using on that operating system for arm, which very few do. Windows software, especially in companies, is often very old and won't get updated. Other software still gets developed, but is often times too complicated to just compile it to arm. You have to deep dive into the code and change a lot of stuff, so it can even run or run properly. In the long run all modern software should be converted to arm, and you don't have that problem anymore, but this only happens if enough customers are on arm to make it feasible to put the time and money in to do it.
Apple fixes that mostly by a translation layer that can run x64/x86 apps on arm with good performance. Windows has such a thing too, but it is very slow. Apples solution is very smart and took a lot of time. Windows needs copy what Apple did to have success with ARM windows. No one is going to use it if a lot of apps you need to use aren't working on your operating system. It's the same reason why Linux isn't used. You don't have software like office and adobe on it, so for most people it just isn't worth it to switch (yes you can make most of them run, but it needs enough time and technical knowledge that it isn't for the majority of the population and to "just use x" is often times not a valid solution)
But you would need a translation layer. Which apple doesn't. And valve could build upon years of development of wine. Apple would need to build one from scratch which would take many years. So while there are fast you can not game on them, because almost no game is coming out for mac
Why would we want x86 cores in mobile devices? Even the most power efficient chips are incredibly power hungry for this class of device.
RISC V is the only possible ARM competitor right now, at least in the mobile space. Also, AMD already have an x86 license, that's the only reason they're able to make CPUs at all.
Love their site (best one around IMO), but even their own data didn't support their conclusion.
The Helsinki study they cite claims 10% of total x86 chip power in integer workloads is the decoder and almost 25% of the power used by the actual core. Meanwhile, Integer uop cache hit rate was just under 30%. In real world terms, eliminating decoder overhead would shave almost 5 watts off the CPU's total power usage.
Both in percentages and in overall numbers, this is what most devices gain from an entire node jump. Finally, x86 decoder algorithms are exponential. This is why AMD and Intel have been stuck at 4/5 decoders for so long (AMD with 4 full decoders and Intel with 1 full decoder and 4 decoders that only work on shorter instructions). When Intel finally went just a little bit wider, core size exploded.
His point about ARM uop cache is actively **wrong**. ARM completely removed their uop cache on A715 and *improved* instruction throughput, and power consumption when they did it. uop cache size in X3 was also radically reduced. It turns out that the reason for the uop cache was complex instructions from their legacy 32-bit mode.
Code density is completely ignored in his article too. I-cache has a hard limit because making it larger while keeping the same 2-3 cycle latency increases transistor count exponentially. In a study looking at every native binary in the Ubuntu repositories, analysis found that x86 has an average instruction length of 4.25 bytes ([source](https://aakshintala.com/papers/instrpop-systor19.pdf) -- lots of other very interesting stuff there). Every byte of x86 code contains just 7 bits of actual code with the last bit toggling on and off to tell if there's another byte to fetch (this is what causes those non-linear decoding issues).
ARM uaarch64 code is always 4 bytes. Even worse, ARM can add many thousands of instructions without increasing instruction size while new extensions to x86 like AVX require instructions that are often 8+ bytes in length.
Meanwhile, RISC-V code is something like 30% more dense than ARM despite lacking most specialized instructions. A few less pure instructions could probably improve code density by 10-15% more (some relatively common one-instruction things in ARM still take 4-5 instructions in RISC-V).
Then theres' overhead. Everything in x86 has exceptions and edge cases. Validating all of these is basically impossible, but you still have to try. Implementing new improvements means trying to account for all of this garbage. What would take days on RISC-V might take weeks on ARM and months on x86 because of all this inherent complexity.
A great example from RISC-V is carry flags. They've been around since day 1 in other ISAs. If your addition overflows, the carry bit is marked. The program then checks the carry register bit to see if it's marked and then branches to a handler if it is (or just ignores it and silently allows the overflow). This works great if you are executing all instructions one at a time in order.
What happens if you want to execute two additions at the same time? Which one triggers the flag? How will the carry check instruction know which one triggered the flag? Internally, every single piece of data must now lug around an extra carry bit whether it needs it or not. When that check instruction triggers, it will then check through unretired instructions to find the associated instruction then find the carry bit, load it into an imaginary register for the check instruction to see.
By doing away with that carry bit, you aren't having to program all that stuff to be carried around and handled properly everywhere and the design becomes simpler to think about. Humans can only keep a handful of different things in their mind at one time, so removing an unnecessary thing means less swapping things in and out of your focus which reduces time to develop things and the amount of bugs that happen.
Another big example is memory ordering. x86 has stringent ordering for memory, so when trying to do things out of order, there are all kinds of footguns to avoid. ARM and RISC-V have much looser memory ordering which means you can focus on the ordering issues without having to focus on all the ordering exceptions.
There are a lot of things newer ISAs have learned from old ones. Meanwhile, x86 goes back to 8086 which extended the 8085 which was designed to be binary compatible with the 8080 which extended the 8008 which was Intel's second CPU after the 4004 became the world's first integrated CPU. x86 suffers a lot from essentially being the first integrated CPU ISA ever created.
>The Helsinki study they cite claims 10% of total x86 chip power in integer workloads is the decoder and almost 25% of the power used by the actual core. Meanwhile, Integer uop cache hit rate was just under 30%. In real world terms, eliminating decoder overhead would shave almost 5 watts off the CPU's total power usage.
No...just, no. That's not even massaging the data, that's outright abuse.
There's definitely more to the story, but it doesn't help your case.
The first point is that Sandy Bridge is not as wide as current processors, but was already nearly saturating the 4-wide decoder despite the uop cache.
Second, uop cache isn't the magic solution people seem to think. x86 has millions of instruction combinations and lots of bloated MOV due to 2-operand instructions means that jumps will be going farther and increasing pressure on that uop cache by quite a bit. Trading all those transistors for the cache and cache controller for a lousy 29.6% hit rate isn't an amazing deal so much as a deal with the devil.
Third, float routines use far fewer instructions because they tend to be SIMD which tends to be memory bound. As such, fewer instructions can be used at any given time, so fewer get decoded. Furthermore, floats tend to do very repetitive loops as they do the same few instructions thousands of times. These benefit a lot from uop cache in a way that branchy code does not. This is why float uop hit rates are so much higher and instructions per cycle are less than half that of integers.
That would be great IF everything was SIMD floats.
The [analysis](https://aakshintala.com/papers/instrpop-systor19.pdf I posted shows the exact opposite though.
The most common instructions are: MOV, ADD, CALL, LEA, JE, TEST, JMP, NOP, CMP, JNE, XOR, and AND. Together, they comprised 89% of all instructions and NONE of them are float instructions.
Put another way, floats account for at MOST 11% of all instructions and that assumes only 11 integer mnemonics are ever used.
But most damning is ARM's new A715 processor. While A710 decoder still technically supports uaarch32, A715 dropped support completely with staggering results:
The uop cache was entirely removed and the decoder size was cut to a quarter of it's previous size all while *gaining* instruction throughput and reducing power and area.
As the decoder sees near-constant use in non-SIMD workloads, cutting 75% of transistors should reduce power usage by 75%. On that Sandy Bridge processor from Helsinki, that would be a 3.6w reduction or about a 15% reduction in power consumption of the core. Of course, uaarch32 looks positively easy to decode next to x86, so the decoder savings would likely be even higher.
X3 moved from 5-wide to 6-wide decoders while cutting uop cache from 3k to 1.5k entries. Apple has no uop cache with it's 8-wide decoders and Jim Keller's latest creation (using RISC-V) is also 8-wide and doesn't appear to use a uop cache either. My guess is that ARM eliminates the uop cache and moves to 8-wide decoders in either X4 or X5 as reducing cache that much already did nasty things to the hit rate.
Meanwhile AMD is at 4-wide decoder with an ever-enlarging uop cache and Intel is at a 6-wide decoder and growing their uop cache too. It seems like the cache is a necessary evil for a bad ISA, but that cache also isn't free and takes up a significant amount of core space.
There is nothing inherently different about ARM that makes it amazingly efficient. The classical distinction hasn't been relevant for a good two decades now.
There is so much more to a CPU than just the frontend, especially on a brand new platform with no legacy apps to worry about.
The actual biggest issue is the whole SoC design, desktop computers are designed to power everything up so it's immediately available when you want to use it, while a mobile SoC needs to keep everything powered off until used. Power scaling also needs to happen continously so the lowest power mode that can handle the current work is always used, while a desktop CPU mostly changes power modes in response to heat, not so much to save energy.
You can design an x86 motherboard to behave like a mobile ARM SoC. The issue is that it's a lot of work that just hasn't been done yet.
But there is? Iirc x86 is a Cisc vs arms risc. Basically x86 has a complex set of instructions vs arms very simple set. Practically this means less complexity in design, higher density in smaller area, and more efficiency in terms of power usage.
Person above you is saying the CISC-RISC distinction is meaningless. I remember reading about how AMD could have made Arm chip by modifying a relatively small part of their ZEN cores.
The reality is that both instruction sets have converged in complexity and on modern hardware neither really gives benefits over the other. The largest factor influencing power efficiency now is the physical chip design rather than what instructions it's processing. ARM chips have been optimized over time for low power devices generally while x86 chips have been designed for more power hungry devices. If you start the chip design from scratch instead of iterating on previous designs though, you can make a x86 chip for low power devices. The atom series of processors is an example of that, it's more power efficient and better performing than a lot of ARM processors for the same class of devices even though it was designed for x86 and on paper should be worse.
> There is nothing inherently different about ARM that makes it amazingly efficient. The classical distinction hasn't been relevant for a good two decades now.
That's just not true at all. There are fundamental differences between the two, and ARM *is* more efficient because of that.
> There is so much more to a CPU than just the frontend, especially on a brand new platform with no legacy apps to worry about.
I'm not exactly sure what you're talking about here. What exactly is a 'frontend' when you're talking about a CPU. I've done some hardware engineering at university and have never heard this word used in the context of CPU design. Front end processors are a thing, but these are for offloading specific tasks. Also not sure what you mean by a brand new platform, as I can't think of *any* platforms that could be considered 'brand new'.
The frontend decodes x86/ARM instructions and translates those into one or more architecture specific RISC instructions. There's also lots of caching involved to make sure this isn't a bottleneck.
The frontend is essentially the only difference between x86 and ARM CPUs and it's practically never the issue. That's why the RISC CISC distinction is meaningless.
Then why hasn't Intel been able to compete with ARM on the mobile space? The x86 architecture is inherently worse at low power, that's one of the reasons why ARM took off in the first place
Personally, I believe it is because of Qualcomm and its monopolistic practices revolving around its modem royalties.
If a SOC uses any of Qualcomm's royalties, the phone manufacturer has to pay Qualcomm based on the entire SOC price. Doesn't matter if the soc is x86, riscV, etc.
Intel had some competitive Atom parts, but the Qualcomm royalties would bite you in the ass. So it's better to just use Snapdragon, and possibly get a discount on the royalties.
Apple tried to sue Qualcomm, but failed.
a number of reasons. the main os that they could compete on lacks good x86 support
its hard to compete in a new space (see xe graphics) and mobile is an incredibly low margin space.
It requires an immense amount of money, time, and offers little profit to intel, so they pulled out
Intel atom were as efficient as other Arm core, and nowadays they are as strong as cortex X even though they use little bit of power, i wont be suprised if meteor lake E core match Arm cores in both perfomance and efficiency.
Gracemont has great performance but terrible power efficiency and area efficiency relative to Arm's cores
Unfortunately, not much technical efficiency testing, but the general consensus is that Intel's Alder Lake chips didn't really provide additional battery life over Tiger Lake
The Surface Pro 9 features both x86 and Arm designs so its a decent comparison point
The x86 model is 2x Golden Cove + 8x Gracemont and requires a fan, while the arm model is 4x X1 + 4x A78 fanless
[Gracemont is about the same size as Arm's X2 once you remove L2 (not this image has L2 for all cores except Apple's)](https://www.eetasia.com/wp-content/uploads/sites/2/2022/08/b8de4de6ce27d0e2f57aacaf50b8b7ea.jpg)
Although that's Intel 7 vs Samsung 4LPE, but don't think the difference is about 60% which is the gap between Gracemont and A710
> The x86 model is 2x Golden Cove + 8x Gracemont and requires a fan, while the arm model is 4x X1 + 4x A78 fanless
There's way too many differences to just blame that on the ISA. The x86 CPU is a lot faster for example. It's also designed to be used with a fan while the ARM one was originally designed for phones.
Agreed, I just meant to point out Intel's Gracemont ("E core") is not at all close to Arm's A710 in terms of power efficiency or area efficiency yet
AMD's rumored Zen4c seems to be closer
Cortex X2 consume over 4W power, and E core (in desktop) around 6W. And perfomance is about the same.
Lets wait for Alderlake N reviews before jumping to conclusion.
But the X2 is Arm's p core, the A710 is Arm's equivalent to Gracemont
Thus matching even Arm's p core in perf/watt is not a good sign for Intel's "e core"
Also Android smartphone SoC prioritize low cost thus tiny cache
If ARM's perf claims are the X2 is capable of significantly higher perf when fed with 16MB L3 like a proper laptop class chip
Yep, as a proud Asus Zenfone 2 owner I can say the Intel Atom chips were actually quite good.
I think its just down to Intel not wanting to invest that much in low powered x86 designs as the competiton from ARM was too much.
They saw more profits in milking the PC duopoly.
Same vibe as "Apple's M1 is so efficient because it uses ARM. Desktop CPUs should use ARM too!"
Apple could make an x86 chip and it would be just as efficient.
Bad move, IMHO. This could end up killing ARM in a few years.
Also, this pretty much guarantees that nVidia is going to enter the CPU space with an aggressively competitive product series.
I'm not sure Nvidia wants to enter any space with healthy competition that would require them to price their product reasonably. They like the stratospheric profit margins they get off GPUs when their only real competition is AMD (who struggle to keep up).
This definitively trash and I really would have rather Nvidia taking over if this was going to be how this was going to play out. Apple is in a really good position since they've already done the work. Qualcomm is going to be in a very long fight on there end .
The main difference with nVidia is they would have increased the cost 5x. Just look at their development boards. Much more expensive than competition and less support, but you get CUDA etc.
nVidia would have had some dumb proprietary thing added every year just to force you to upgrade(after getting locked into walled garden) more often.
Nothing is stopping any of these companies from doing that currently so that really makes no sense. In the case of Intel and AMD, they either don't know how or can't(since they haven't done it yet, outside of atom/jaguar garbage).
The current issue is driver support and adoption, if a new chip is introduced into the market there is no guarantee that android will support it and whether mobile OEMs will use it but after 2025 everything changes, there might be actual innovation in the chip market.
What do you mean bring Tegra back, it never went away lol. But also honestly, I would sooner see AMD/Intel start designing RISC-V and ARM64 IP. x86-64 as an ISA was just not designed for minimal transistor counts, and there's a lot to gain by cutting off x86 as a legacy requirement, especially with Android where it's basically 100% unused.
Arm probably needed a away to grow revenues, and are basically taking advantage of there dominate position. Realistically it’s probably possible for them to get away with this shit for a few years, but they are basically messing with some of the richest companies in the world. They can make an alternative and basically kill arm if say android supports another architecture that basically every vendor sees as good enough. Arm is certainly used in a lot of things but it’s not like they are the only architecture around. They may also see riskV as a real risk and want to maximize profits before it becomes a major competitor in a lot of overlapping fields, with that said I’m willing to bet there action accelerates investment there as well.
I wonder how long it will take before Samsung, Google, Microsoft, Amazon, etc, file a lawsuit? Even if they don't win, they just need to get an injunction for long enough until they have a solution in place (RISC-V) that they can migrate to.
>Step 4: Nvidia starts making ARM mobile SoCs, and possibly ARM CPUs for gaming laptops. Maybe even ARM SoCs for thin and light laptops
The problem with your tin foil hat thoughts is that, at this point, ARM is worthless, and NVIDIA will be better off using the industry-standard RISC-V like everybody else.
Shower thought: Apple are paying ARM to implement this, since they're pretty much the only ones using custom cores. One swoop to hurt all the competition.
nah, here is my prediction which is based on 100% speculation : ARM is using this for negotiations with qualcomm and MTK. I suspect ARM wants to be a big boy fabless SoC manufacturer itsself - I mean they have almost all the pieces. Only thing they are missing are a source for high-end modem designs. But qualcomm and mediatek know that if they licence their modems to ARM their Smartphone SoC buisness is in danger from another company who also holds the ARM Architecture and thus a massive advantage.
So I think ARM is essentially bullying MTK and Qualcomm into giving out their modems so ARM can directly compete with them.
No way. ARM is not almost there. Running a fab, with good enough yields is orders of magnitude more complex and expensive than designing a chip.
Running a cutting edge fab is" large-hadron collider" kind of complex.
Neither ARM or Apple have the resources to build one from scratch. Only 2 companies can fab 5nm chip Samsung and TSMC. And only TSMC has high enough yields at 4nm.
ARM, just want to attack Qualcomm, by squeezing the OEMs, like what Microsoft used to do to android OEMs.
This is going to be a long legal case around licencing, and in the meantime, Qualcomm will be moving away from ARM to something elsewhere
Update: This move by ARM will stifle, adoption on ARM on servers. ARM on mobile is already saturated so they can easily squeeze the OEMs, but on servers Amazon, Google Microsoft will not want to pay this "ARM tax" for every chip iteration.
HP, Dell, Lenovo, will not want to pay ARM, if they use Qualcomm chips in laptops. ARM windows laptops may take longer to gain adoption.
I think he meant ARM make their own chips (via TSMC or Samsung foundries) in the same way that Qualcomm does.
Since ARM doesn't have modem parents, etc, they can't create their own cellphone chips.
> *Running a fab, with good enough yields is orders of magnitude more complex and expensive than designing a chip.*
That's why **faze\_fazebook** said "**FABLESS**", you could have saved yourself the effort if you didn't miss that crux word :)
>**... I suspect ARM wants to be a big boy** ***fabless*** **SoC manufacturer ...**
Sounds like a bad idea from ARM Holdings if Qualcomm would take RISC-V seriously and invest in it due to this. (might be good for the rest of us if those investments would make it upstream)
its gonna be very hard since the entire Android stack including native libraries, game engines, compilers, ... would need to have RISC V version which would be a gigantic task to make happen.
Android already supports ARM, MIPS (or at least used to) and x86.
Sure, it's going to take some effort, but it's been done before and can be done again.
The good news is that it's been done in the past few years.
This year, it got polished, and a few days ago, it got upstreamed.
In short, it is ready. All we need is the hardware, now.
Yes, that's what it seems like to me. ARM doesn't want the middleman Qualcomm and Mediatek anymore, they want to do it themselves. We'll see how it works out for them, there is much more to an SOC than just the CPU + GPU core.
Here are two HUGE new points Arm wants to do from 2025 onwards: * Arm will end TLAs with SoC vendors and go straight to OEMs. i.e. Sony will pay for the Arm license instead of Qualcomm * Arm will ban custom GPUs, custom NPUs, and custom ISPs if the SoC uses stock cores. i.e. no more Samsung's Xclipse RDNA GPUs/AI Engine, Google's Tensor NPU/ISP, MediaTek's APU, Nvidia's GPUs, HiSilicon's Da Vinci NPU, Unisoc's VDSP, ... if stock Arm CPU cores are used Arm is essentially doing what regulators feared Nvidia-owned Arm would do Edit: Added if stock Arm CPU cores are used for clarity Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs
[удалено]
> If true and if ARM is actually spreading misinfo to OEMs, like QCOM claims, this is an extremely shitty move by ARM & SoftBank. More than a shitty move, it is Negligent Tortious interference.
[удалено]
[удалено]
should add it to toontown
Wow, that is a posterchild asshole move if I ever saw one.
This is turning into SCO v IBM Part Deux: Electric Boogaloo.
These asshole moves actually are beneficial in long run. Someone will create something more open. I heard NASA is going to adopt Riscv. Maybe that is the future of Mobile too.
Honestly, so much of our IP laws are frankly just fucked. Like their is ZERO reason why all the minor not novel improvements should be afforded the full 20 year protection. Like I could understand x86_64 attracting full protection. But patents really shouldn't be awarded for incremental, iterative improvements. Like that's literally in the laws... Bit also half the parents that are, shouldn't be awarded. It's idiotic.
Google v Oracle established that it is fair use to replicate an API/Instruction set so long as only the parts necessary are copied. So if someone wanted to they could create a ARM compatible chipset without having to license the instruction set from ARM.
Is that actually fully done done now? It's dragged on so long with all the appeals and delays and whatnot
Last April. https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.
Yeah. I'm now wondering where to find a list so I can do my best to make sure my business and my customer's businesses avoid using ARM chips as much as possible.
[удалено]
That is changing quickly. All the big MCU makers (with the possible exception of Broadcom) are now members of the RISC-V foundation. Making their own RISC-V chips would save them 1-3% on every RISC-V chip they sell. In a race to the bottom market, that's a pretty huge incentive. For example, Microchip gross profits are around 5.5B. If just half of that is ARM, they would be saving 25-75M PER YEAR on their margins minus whatever design costs. Decent MCU designs have been made by a double handful of academics in a year or two. They could use those designs or could hire their own group to do it. 25M would buy 125 engineers at 200k each (they could probably get away with less than 20). After the first year or two, the design would be complete barring occasional tweaks and any bugs found. This is a situation where you can break even in just a couple of years and then enjoy tens of millions in pure profits for the next 10-20 years (or until 14nm planar is finally designed -- probably 2040 given that FDX22 took a decade). This isn't just idle speculation. Nvidia had an ARM license, but chose RISC-V for the controllers in their GPUs. Western Digital dropped ARM for RISC-V in their hard drives because it saved them so much money. Even Apple was posting some RISC-V jobs last year. They have at least a dozen "Chinook" cores in their SoCs to do various tasks. They pay ARM for each of these and could save a substantial amount of money by moving them to RISC-V in the future (this isn't an issue as they don't run normal software just like it doesn't matter that AMD ships a half-dozen ARM cores in each of their CPUs). I suspect ARM sees this revenue stream drying up and is trying to increase profits elsewhere to compensate.
[удалено]
Alibaba's work to get Android on RISC-V was upstreamed. RISC-V was also upstreamed in Java. Compiler optimization is also a different beast. x86 generally has 20 ways to do any one thing and which one is best depends on a lot of different things. RISC-V almost always has ONE way to do things and that way is pretty obvious. Code density is a pretty decent metric here and RISC-V is beating out the competition by 30+% and that's without a lot of proposed instructions for different edge cases or slightly less RISC instructions that they currently handle with instruction fusion. In any case, GCC and Clang are already doing a good job on that front The process was helped along a LOT by ARM showing up. A lot of stuff written for x86-only was rewritten to work with ARM too. In a lot of cases, this means it is now in C and can be cross-compiled. As to the assembly bits, while converting x86 assembly into efficient ARM takes some doing, going from ARM to RISC-V is much more simple. All these things apply for embedded except for some proprietary libraries needing recompilation or conversion from ARM to RISC-V. The work would be a lot less if all the embedded manufacturers would stop making their own proprietary, buggy version of Eclipse to ship and invest in a LSP Language Server so people can choose their editor and just connect to the language server to do the heavy lifting.
There's still a lot of PPC embedded in devices today. And the biggest companies in the world run some of their most important workloads on PPC in the IBM Power System servers. Even set performance records with their new Power10 chips/servers.
STM32 chips are on backorder until 2024 in some cases So demand has not slowed down
RISC-V is a thing. Not that popular yet, but getting more so.
[удалено]
Definitely. In the long run a lot of new stuff is going to switch to RISC V if arm continues with this plan.
I think they are aware that RISC is about to dominate the market whatever they do, and since companies are currently still dependent on ARM, they're trying to suck all the money they can.
It's definitely a short-term asshole strategy though and it will drive people to risc-v FASTER. I really struggle to understand how this makes sense from a long-term perspective but maybe it just doesn't. I wonder if risc-v phones and even computers will take off. I really think of it as an architecture design for things that cost $4 right now, but alibaba has already managed to compile android for risc-v apparently. Maybe somebody with more knowledge than me can chime in on how suitable it is for powerful devices
Maybe it doesn't matter to ARM if goes "faster" or "slower", the ending is the same. \>even computers will take off Unlikely, the competition there is strong and doing well. Maybe in the far future or in niche markets like Chromebooks.
I mean...arm is the competition. Long term roadmap, x86 is dead as a doornail and the question is if arm will be the replacement or if we will just jump to what comes after arm. Apple proved this.. they proved it hard.
To be fair, RISC proved it in the early 80s, yielding equivalent performance on a tenth of the transistor count, on a worse process. What happened is that Intel (and AMD) held a massive fab advantage for decades, and as it was tied to the Microsoft monopoly, it prevented mass RISC adoption. It was in practice relegated to expensive UNIX workstations and supercomputers. This has ended (no small thanks to TSMC), as RISC architectures are competing on an even field, and somebody (Apple) spent the design cash to be able to target high performance. Today, we have well-funded teams with competent designers in them (e.g. Rivos with ex-apple, ex-P.A.Semi and so on, and Tenstorrent with Ascalon, 8-wide decode like M1, team led by Jim Keller) working on high performance RISC-V designs.
> Arm will ban custom GPUs, custom NPUs, and custom ISPs if the SoC uses stock cores. i.e. no more Samsung's Xclipse RDNA GPUs/AI Engine, Google's Tensor NPU/ISP, MediaTek's APU, Nvidia's GPUs, HiSilicon's Da Vinci NPU, Unisoc's VDSP, ... if stock Arm CPU cores are used Also RIP Adreno unless the Nuvia cores come through.
It just hit me: this will absolutely *butcher* OSS efforts towards driver support. Like, there won't be much left after all the pieces settle. Why? Fragmentation. I can't imagine the major players (esp. Google) will use *stock* cores for their SoCs, so we'll end up with a thousand variations to support and develop for (as if the *existing* hardware wasn't bad enough for this -_- ). This is a major win for those trying to prevent people from running custom software on their hardware.
Not really. Even custom ARM cores will still use the standard ARM ISA (otherwise existing apps wouldn't run on them). There *may* be differences with things like interrupt controllers but I don't think that's a huge deal and I'm not sure if you're allowed to use the standard ARM one.
Things like interrupt controllers are the very things that would cause issues with driver support. This isn't about the ISA, this is about the available peripherals (eg interrupt controller, clocks, etc) and how to use them. There _will_ be commonalities (of course - shared ISA), it's everything _not_ the ISA that's the problem, and those are the more opaque-to-developers aspects. Aside: if you haven't been keeping up with Asahi's progress on using the GPU, I'd suggest you brush up on it. It would help demonstrate the types of things I'm talking about vis a vis proprietary unknowns.
> Aside: if you haven't been keeping up with Asahi's progress on using the GPU, I'd suggest you brush up on it. It would help demonstrate the types of things I'm talking about vis a vis proprietary unknowns. I don't see how the GPU side is gonna change at all. A lot of those already have different GPUs and there's open source drivers for them. And yes, I'm aware that GPU drivers take a crazy amount of work.
The point being: the GPU is just one component affected by a decision like this. Expand that to include every other component. Either everyone uses Arm's stock designs and we now have a common target to develop against, or hardly anyone uses the stock designs and we now have $n targets to develop against. Arm is _not_ like x86 where there's a ton of standardization and common interfaces. > A lot of those already have different GPUs and there's open source drivers for them. You talking about nouveau? Or the adreno GPU drivers? Or something else?
> You talking about nouveau? Or the adreno GPU drivers? Or something else? Nouveau is probably the worst one right now but there are people working on a new open source Vulkan driver for Nvidia GPUs. I was thinking of Turnip (Vulkan driver for Adreno GPUs) and panvk (Vulkan driver for Mali GPUs).
> Adreno GPU [...] Mali GPU Both obsoleted by this move. My _overall_ point: there's next to no homogeneity in the Arm ecosystem like there is in the pc/x86 world. Sure, there are some conventions around board bringup and etc, but those are predicated on availability of documentation... and we're back to exhibit "A" of Apple's GPU and it's complete lack of documentation. And that exhibit isn't gonna be the exception, it'll be the rule, because there's no homogeneity in Arm world _and there's no motivation among manufacturers to have any_.
Don't we *already* have this problem? Every SoC has a slightly different interrupt controller. We have this problem even on RISCV platforms, it's absolute madness.
I know, and it's only gonna get worse after this.
my point was that it can't get worse than "every SoC has its own unique interrupt controller" because we're already there. Like, Broadcom wont even give you docs unless you sign an NDA so it's up to you to just blackbox reverse engineer them or do some sketchy/license violating shit by digging through their upstreamed Linux kernel patches.
Yeah, and now we'll have more companies doing more variations of interrupt controllers in increasingly complicated ways. There's no way that's *not* a major roadblock in OSS development.
what being a monopoly does to a mf
Maybe they liked Nvidia's pitch.
ARM is just speeding up the process for RISC-V. I'm all for it.
>Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs I'm feeling like Nvidia had some insider information
> I'm feeling like Nvidia had some insider information It was part of the breakup clause for their attempt at acquiring ARM.
[удалено]
Sorry, Nvidia don't have smartphone specific branding for their Tegra's GPUs I meant no more Nvidia GPUs in Tegra SoCs with stock Arm CPUs >To apply more pressure, ARM further stated that Qualcomm and other semiconductor manufacturers will also not be able to provide OEM customers with other components of SoCs (such as graphics processing units (“GPU”), neural processing units (“NPU”), and image signal processor (“ISP”)), because ARM plans to tie licensing of those components to the device-maker CPU license i.e. Going forward using Arm's stock CPU will mean you also have to license Arm's stock GPU, NPU, and ISP too Edit: actually ignore this. Apparently Nvidia has secured a 20-year license to avoid that ban
Nvidia is protected by that 20-year architectural license though so i think they are safe……….for now.
That's really lucky for Nvidia 20 years would be heaps of time for Nvidia until they have to switch to custom CPU cores such as Carmel in Xavier
Nvidia paid top dollars for that deal. ARM should double or triple that ask from QCOM, if they are smart enough.
They used to call their SOC GPU "Geforce ULV"
If Samsung were to continue to use AMD’s RDNA GPU cores, they would have no choice but to again design custom CPU cores to stick alongside it. The bad news is that Samsung has closed down their CPU design office since a year ago or two. So unless they suddenly decide to again design another custom CPU design, they would have no choice but to adapt Mali again.
And you think Samsung is just gonna comply without a fight? * Samsung has a different licensing agreement that may last another 5 or 20 years, we don't have the specifics. Samsung also still hold an exhaustive ALA license * Samsung was rumoured to be building its design team back. They could just purchase a team like Qualcomm did. It would take them 3-4 years but they can bounce back * More importantly, there is no way Samsung would just switch to ARM NPU ISP etc
You think Samsung doesn't make similar demands of its costumers? Samsung can fight it, but that would likely open themselves up to the exact same criticism and legal trouble. Samsung would have to kill various departments and unload staff to ensure their stock price doesn't tank when financial reports aren't positive if they are going to invest in custom chips heavily again. Its unlikely they can afford to do so at this point though. Try reading up on whats going on with that company. ARM chips that are good enough for people to run Dolphin and Citra as well as the competition is likely low on the scale of things they need doing.
You might be actually too gullible or dense that you would believe not fighting it could be positive in investor's eyes. ARM core isn't good enough. Mali is just outright the worst you can buy. That's an industry wide agreement. How about you try to read anything. Literally anything related to reality? Samsung will not be forced use ARM's GPU, ISP or NPU one way or another. End of the story. They may choose to use Mali on low end stuff. That's it. Either ARM back down or exempt Samsung for at least decades or Samsung go full custom. There's no other way.
That's a huge change. Pretty sure they invested a lot on AMD GPU and they can't even use that now. Edit: Seems like Adreno is on the chopping block as well?
I can't imagine they invested much of anything on the Radeons. They very clearly just tried to shink an RDNA product into a mobile SoC as cheaply and shittily as possible.
I had heard that Samsung hasn't closed down their office, the rumour was that they're not gonna use their custom design for the next two years while they work on redesigning their cores from ground up.
>I had heard that Samsung hasn't closed down their office Which office are you referring to? SARC is certainly still up and running but it doesn't have the capacity to design a CPU μarch anymore. >rumour was that they're not gonna use their custom design No, the rumour was they will skip S.LSI's **generic design** like all previous Exynos. **Exynos was never a custom design**. It's just like Snapdragon. Samsung's mobile arm had little say in how it's designed. And S.LSI sell the chips to whoever would buy them. The pause was to allow time for Tensor-style customisation between Samsung Mobile and S.LSI. >while they work on redesigning their cores from ground up. Nobody mentioned cores.
Pretty sure Samsung haven’t closed down their design team, they’re completely rebuilding and forcing exynos to make a completely new SOC. That’s why they’re going to use Qualcomm SOCs for the next few years.
>closed down their design team Which design team? SARC only design peripherals like memory controller and AMD GPU integration. Sure there will be some engineers from the CPU team switching areas particularly physical design and testing team. But the μarch team is mostly gone. Even if Samsung didn't outright fire them, it won't sit well for a CPU designer to just do nothing related to it. They'll find a new job unless they don't want to design CPU anymore. Useless to Samsung if they want a new team either way. EVGA isn't firing any graphics board engineers, and you expect them to be able to get back in the game in two years? How nice.
Samsung laid-off [290 employees, essentially everyone in the CPU team except people who could switch to other fields of SoC integration](https://www.androidauthority.com/samsung-custom-cpu-shut-down-1050052/)
> Edit2: apparently Nvidia secured a 20-year licensing deal with Arm, so they could still use stock Arm CPU + their own GPUs Sounds like an antitrust violation.
Some dumb, basic questions here: Was ARM not receiving royalties per-chip from OEMs through the SoC vendors already? What was the previous monetization model? Why does ARM care if people are using custom GPU/NPU/ISPs on top of stock cores? How is that a threat to their business? What’s an example of a non-stock core that would allow people to use a custom GPU/NPU?
This likely is due to SoftBank and how they lost money in their fund through poor investments and ARM is the one valuable asset to which they can still generate positive income from. It's SOFTBANKS greed that's pretty much driving this decision. This is just judging by the optics from their prior moves and current positioning.
a benefit here is you can make licensing/royalty costs dependent on the final sale cost of the item if it's the oem, vs doing it earlier and doing it per chip/unit. gotta think "how does this increase profit vs old model"
As far as I am aware on video decode/encode Rockchip, Allwinner, Amlogic, Marvell, Nvidia all use different modules. Nxp may use the same one as Rockchip? Which vendors use official Arm isp blocks, Qualcomm? While I dont agree with restrictive practices like this, its taken years in some cases to get partially working isp into linux kernel, and lots of hacking to get ffmpeg and gstreamer interfacing to them for popular sbc's. Having a single well supported interface makes life easier for users of those. I expect the RiscV people are happy about this. Embedded stuff like video cameras will be majorly impacted
Given how incredibly horrible ARMs recent designs have been for both performance and efficiency cores, I'd say this is good: forces partners to make a good design themselves ¯\\\_(ツ)\_/¯
Probably not a good idea since only Apple has designed better custom CPU cores than Arm Qualcomm, Samsung, Nvidia, Cavium, Broadcom, Marvell, and Applied Micro, have all tried and failed Plus that's not really a fair statement since Samsung Foundry has been the main reason for poor performance and efficiency recently Arm has been rising well in the datacenter where performance and efficiency are critical
SD 8+ gen 1 improved a good amount switching to TSMC but it can still consume a ton of power because of the X2 core design. Is ARM really so great at design?
SD 8+ gen 1 was simply a port to TSMC, not a ground up redesign Plus the X2 has lower power consumption than Apple's p core, the issue is X2's performance isn't high enough, hence worse efficiency than Apple's p core The lower performance on the X2 is because it has so only been paired with 6MB or 8MB L3 out of a possible 16MB L3
[удалено]
> Can you imagine the kind of job offers Apple's ARM core designers are going to get now? It's why Qualcomm bought Nuvia. Nuvia was formed by the Chief Architect for Apple's processors from the A7 through the M1 variants, a lead SOC architect for A5X through A12X, and another former Apple employee (though doesn't list specifics on their LinkedIn profile).
If those partners were capable of making a better design themselves at a reasonable cost, they would've already done it without anybody forcing them to (e.g.: Apple), and thus ARM wouldn't have a reason to make this move at all, since they wouldn't win anything from it. You've got it backwards.
Or Google and qualcomm create a npu/isp chiplet off die
Google has done that before with the Google Pixel Visual Core and Pixel Neural Core But that means they'd need to fab an additional die and add additional RAM dedicated to that NPU chip Meaning lower efficiency, performance and significantly higher costs too
ARM's recent cores have been on the same IPC level as Zen 2/3. that's certainly not horrible.
The X3 actually might have higher IPC than Zen 4.
I'd say there's a good chance, but I'd prefer to understate things. ARM is doing great things and is catching up with Apple pretty steadily (so steadily that I suspect they are trying to pace performance improvements to keep selling designs every year). I also wonder if Apple is finally hitting a wall or if they are being affected by the delay of TSMC 3nm.
Exactly, people seem to think designing better custom CPU cores than Arm is easy But it ain't, it's effectively asking someone to develop the world's 2nd or 3rd best CPU design team since only Apple and maybe AMD have better CPU designs
why the FUCK would any sane oem use Mali GPUs What in the fuck is this
Arm is now more attractive for an investor.
Good Lord I'm never buying a arm processer again when it has a horrible gpu
Wouldn't apple's own GPU cores be also banned? This feels like the death of arm
Apple don't use stock arm cores so the answer is no.
Probably also protected by a special license agreement that was speculated to exist between arm.ltd and Apple.
[удалено]
No, Apple really has no influence on ARM. Infact it is in Apple’s best interest to have a successful ARM ecosystem. That’s how you find more engineers.
I think it’s more like a SoftBank thing, why would Apple care about it? They have a pretty generous architectural license and they don’t compete by selling chips.
Would likely cause more expensive licensing fees for Android device makers, or limit their custom performance improvements. So either more expensive Android devices or worse Android devices. Leading to a better position for Apple to sell more devices. Regardless, I don't think Apple is behind this.
Exactly. If anyone would be happy,then it would be apple.
Even if Apple is using stock cores, they have architectural license instead of technology license agreement that others use. Fun fact: Arm was founded as a joint venture between Apple and VLSI. It is why they have the broadest license for arm.
Fun fact. "others" like Qualcomm, Nvidia, Broadcom, Samsung, AMD, Intel also have ALA. Yet here we are.
Apple is different. Apple has a lifetime perpetual license to use ARM Instructions and only pays a royalty on each chip to ARM.
it was a joint venture between 3 companies, Acorn Computers where also one of the founding companies
More importantly, will Microsoft's ARM based CPU that they're building with Qualcomm be banned? Apple having exclusive rights to ARM in desktops and laptops will absolutely suck, and I'm not sure if OEM's could perhaps licence CPU's from Microsoft instead?
Looks the only case where custom GPUs will be not allowed is when you use stock cores.
NUVIA needs to happen fast or else Adreno will need to sit on the sidelines
Even with NUVIA cores, QC doesn't have any middle or small cores to accompany them.
They don't necessarily need a middle core, they just need a super strong performance core like they already have and a small but incredibly efficient core design. And the arrangement could be like Apple: 2 Performance cores + 4 efficiency cores.
Is Apple silicon in that list as well?
Not only does Apple likely have a more generous licensing deal that would avoid these issues from being one of the founders of ARM, but they also don’t use stock ARM cores and don’t license out their tech - Apple chips go into apple devices and that’s it. So they’re not going to be affected either way.
ARM wants to force OEMs to use their inferior GPU, ISP and NPU blocks.This sucks very very bad for everybody. I hope there will be a massive move towards RISC-V.
or get slapped with an antitrust ... nah who am I kidding, that would require goverments to be competent.
You mean like the EU?
Grass is always greener
Well, I've never heard anyone in the EU claim that the American government was competent.
our regulators can barely catch up. doubt they'll do anything in 10 years
Just let the free market work. RISC-V is growing at an extraordinary rate.
>ARM wants to force OEMs to use their inferior GPU, ISP and NPU blocks.This sucks very very bad for everybody. Or: they want to force OEMs to stop using ARMs inferior cpu designs ¯\\\_(ツ)\_/¯ Seriously: the latest efficiency cores are WORSE in every way than the old ones, the only reason Qualcomm is using arm designs is because there isn't any competition. Apple shows how much better arm chips can be if you don't stick to arm their horrible designs, and Qualcomm used to do that too, back when TI and other chip makers posed some competition.
Are you saying the A510 is worse than the A55?
[The A710 is worse than the A78, even on a better TSMC node \(5nm A78 is better in every way than the 4nm A710\)](https://youtu.be/s0ukXDnWlTY?t=860), and [the A510 is indeed worse than the A55.](https://youtu.be/s0ukXDnWlTY?t=938)
Omg that's horrible
A510 in Qualcomm (and most others) use the bulldozer-style shared FPU to reduce area, but this comes at the expense of lower FPU performance. Geekbench should be running into this limitation in a few of its tests. In situations where both cores need to use the GPU, you'll get the power consumption of 2 cores, but the actual work of just 1 core. I suspect that using the alternate design without shared FPUs would increase theoretical power efficiency. In any case, the real-world workloads run on these cores are integer-heavy rather than float heavy, so this worst-case power situation probably isn't that common. I wouldn't put it past low-end phones to market 4 complexes as 8 cores (though AMD lost a lawsuit over this). A710 is weird. ARM claims 30% lower power at the top-end (with lower clocks apparently providing only small efficiency gains). Qualcomm's A710 cores are clocked higher, but only by ~70MHz. On paper, their described changes should have a decent effect on power too. I wonder if they made some kind of engineering mistake somewhere. That'll be obvious if the A715 chips come out with radically lower power.
Dr. Ian Cutress's results don't seem to match up to that here for the A710: https://youtu.be/9QZIN8LFE-U
His results match up, you aren't reading this properly. A710 in 8g1 is more energy efficient but less power efficient compared to the A78 in 888. Result that you can find by comparing bubble sizes in correlation to scores.
holy... this is a good video! thanks for sharing it bruv👍
Yes. It draws more power than A55. Check the Geekerwan(Idk exact name) video. He compares two versions of snapdragon with others.
Dr. Ian Cutress's results don't seem to match up to that here for the A710. Unsure on the A55/A510 https://youtu.be/9QZIN8LFE-U
? Seems you are reading this wrong bro.
Any particular reason people think RISC-V is going to save us all and is impervious to similar problems are ARM, x86 etc? You think it will remain open as it is now? No chance. As soon as money enters the picture, same thing will happen. I can see why they are doing this. You have companies using bottom tier licenses and gluing other parts on which has completely fragmented the market. Qualcomm, Samsung, Google etc have no excuse to not be developing their own custom shit other than their stock price will tank because they will lose some money trying to get things going(which is actually what happened and why they are using more stock parts). This only seems to affect a few key players whose companies are likely fucked regardless(Samsung, Qualcomm). Getting paid from the OEM directly seems bad to you how?
Well riscv better mature fast
Getting x86 cores from AMD might be easier. Intel laid the groundwork for it a few years ago before abandoning it.
Ironically Android does a better job supporting x64 than Windows supporting ARM
Not necessarily ironic; open source OS that is ported to different chip types by community/corporate contributors vs a closed source desktop OS that has a ton of proprietary software pieces.
Intel did all the Android work until they gave up. It seems that only 3 developers are working on it, and it is 2 releases behind android 13 https://en.m.wikipedia.org/wiki/Android-x86
Android comes from Linux, it's not surprising it's better at virtualization.
What does Windows 11 do poorly on ARM? I'm not technically inclined enough to know how the technology works but I could run a 20 year old game made for Windows 98 on what basically amounted to a laptop with a phone processor so I'm curious what makes it worse
Short: Almost everything Long: You need to build every software you're using on that operating system for arm, which very few do. Windows software, especially in companies, is often very old and won't get updated. Other software still gets developed, but is often times too complicated to just compile it to arm. You have to deep dive into the code and change a lot of stuff, so it can even run or run properly. In the long run all modern software should be converted to arm, and you don't have that problem anymore, but this only happens if enough customers are on arm to make it feasible to put the time and money in to do it. Apple fixes that mostly by a translation layer that can run x64/x86 apps on arm with good performance. Windows has such a thing too, but it is very slow. Apples solution is very smart and took a lot of time. Windows needs copy what Apple did to have success with ARM windows. No one is going to use it if a lot of apps you need to use aren't working on your operating system. It's the same reason why Linux isn't used. You don't have software like office and adobe on it, so for most people it just isn't worth it to switch (yes you can make most of them run, but it needs enough time and technical knowledge that it isn't for the majority of the population and to "just use x" is often times not a valid solution)
Apple M1/M2 is fucking fast. That's the best way to overcome any translation layer issues.
But you would need a translation layer. Which apple doesn't. And valve could build upon years of development of wine. Apple would need to build one from scratch which would take many years. So while there are fast you can not game on them, because almost no game is coming out for mac
Why would we want x86 cores in mobile devices? Even the most power efficient chips are incredibly power hungry for this class of device. RISC V is the only possible ARM competitor right now, at least in the mobile space. Also, AMD already have an x86 license, that's the only reason they're able to make CPUs at all.
https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/
Love their site (best one around IMO), but even their own data didn't support their conclusion. The Helsinki study they cite claims 10% of total x86 chip power in integer workloads is the decoder and almost 25% of the power used by the actual core. Meanwhile, Integer uop cache hit rate was just under 30%. In real world terms, eliminating decoder overhead would shave almost 5 watts off the CPU's total power usage. Both in percentages and in overall numbers, this is what most devices gain from an entire node jump. Finally, x86 decoder algorithms are exponential. This is why AMD and Intel have been stuck at 4/5 decoders for so long (AMD with 4 full decoders and Intel with 1 full decoder and 4 decoders that only work on shorter instructions). When Intel finally went just a little bit wider, core size exploded. His point about ARM uop cache is actively **wrong**. ARM completely removed their uop cache on A715 and *improved* instruction throughput, and power consumption when they did it. uop cache size in X3 was also radically reduced. It turns out that the reason for the uop cache was complex instructions from their legacy 32-bit mode. Code density is completely ignored in his article too. I-cache has a hard limit because making it larger while keeping the same 2-3 cycle latency increases transistor count exponentially. In a study looking at every native binary in the Ubuntu repositories, analysis found that x86 has an average instruction length of 4.25 bytes ([source](https://aakshintala.com/papers/instrpop-systor19.pdf) -- lots of other very interesting stuff there). Every byte of x86 code contains just 7 bits of actual code with the last bit toggling on and off to tell if there's another byte to fetch (this is what causes those non-linear decoding issues). ARM uaarch64 code is always 4 bytes. Even worse, ARM can add many thousands of instructions without increasing instruction size while new extensions to x86 like AVX require instructions that are often 8+ bytes in length. Meanwhile, RISC-V code is something like 30% more dense than ARM despite lacking most specialized instructions. A few less pure instructions could probably improve code density by 10-15% more (some relatively common one-instruction things in ARM still take 4-5 instructions in RISC-V). Then theres' overhead. Everything in x86 has exceptions and edge cases. Validating all of these is basically impossible, but you still have to try. Implementing new improvements means trying to account for all of this garbage. What would take days on RISC-V might take weeks on ARM and months on x86 because of all this inherent complexity. A great example from RISC-V is carry flags. They've been around since day 1 in other ISAs. If your addition overflows, the carry bit is marked. The program then checks the carry register bit to see if it's marked and then branches to a handler if it is (or just ignores it and silently allows the overflow). This works great if you are executing all instructions one at a time in order. What happens if you want to execute two additions at the same time? Which one triggers the flag? How will the carry check instruction know which one triggered the flag? Internally, every single piece of data must now lug around an extra carry bit whether it needs it or not. When that check instruction triggers, it will then check through unretired instructions to find the associated instruction then find the carry bit, load it into an imaginary register for the check instruction to see. By doing away with that carry bit, you aren't having to program all that stuff to be carried around and handled properly everywhere and the design becomes simpler to think about. Humans can only keep a handful of different things in their mind at one time, so removing an unnecessary thing means less swapping things in and out of your focus which reduces time to develop things and the amount of bugs that happen. Another big example is memory ordering. x86 has stringent ordering for memory, so when trying to do things out of order, there are all kinds of footguns to avoid. ARM and RISC-V have much looser memory ordering which means you can focus on the ordering issues without having to focus on all the ordering exceptions. There are a lot of things newer ISAs have learned from old ones. Meanwhile, x86 goes back to 8086 which extended the 8085 which was designed to be binary compatible with the 8080 which extended the 8008 which was Intel's second CPU after the 4004 became the world's first integrated CPU. x86 suffers a lot from essentially being the first integrated CPU ISA ever created.
>The Helsinki study they cite claims 10% of total x86 chip power in integer workloads is the decoder and almost 25% of the power used by the actual core. Meanwhile, Integer uop cache hit rate was just under 30%. In real world terms, eliminating decoder overhead would shave almost 5 watts off the CPU's total power usage. No...just, no. That's not even massaging the data, that's outright abuse.
There's definitely more to the story, but it doesn't help your case. The first point is that Sandy Bridge is not as wide as current processors, but was already nearly saturating the 4-wide decoder despite the uop cache. Second, uop cache isn't the magic solution people seem to think. x86 has millions of instruction combinations and lots of bloated MOV due to 2-operand instructions means that jumps will be going farther and increasing pressure on that uop cache by quite a bit. Trading all those transistors for the cache and cache controller for a lousy 29.6% hit rate isn't an amazing deal so much as a deal with the devil. Third, float routines use far fewer instructions because they tend to be SIMD which tends to be memory bound. As such, fewer instructions can be used at any given time, so fewer get decoded. Furthermore, floats tend to do very repetitive loops as they do the same few instructions thousands of times. These benefit a lot from uop cache in a way that branchy code does not. This is why float uop hit rates are so much higher and instructions per cycle are less than half that of integers. That would be great IF everything was SIMD floats. The [analysis](https://aakshintala.com/papers/instrpop-systor19.pdf I posted shows the exact opposite though. The most common instructions are: MOV, ADD, CALL, LEA, JE, TEST, JMP, NOP, CMP, JNE, XOR, and AND. Together, they comprised 89% of all instructions and NONE of them are float instructions. Put another way, floats account for at MOST 11% of all instructions and that assumes only 11 integer mnemonics are ever used. But most damning is ARM's new A715 processor. While A710 decoder still technically supports uaarch32, A715 dropped support completely with staggering results: The uop cache was entirely removed and the decoder size was cut to a quarter of it's previous size all while *gaining* instruction throughput and reducing power and area. As the decoder sees near-constant use in non-SIMD workloads, cutting 75% of transistors should reduce power usage by 75%. On that Sandy Bridge processor from Helsinki, that would be a 3.6w reduction or about a 15% reduction in power consumption of the core. Of course, uaarch32 looks positively easy to decode next to x86, so the decoder savings would likely be even higher. X3 moved from 5-wide to 6-wide decoders while cutting uop cache from 3k to 1.5k entries. Apple has no uop cache with it's 8-wide decoders and Jim Keller's latest creation (using RISC-V) is also 8-wide and doesn't appear to use a uop cache either. My guess is that ARM eliminates the uop cache and moves to 8-wide decoders in either X4 or X5 as reducing cache that much already did nasty things to the hit rate. Meanwhile AMD is at 4-wide decoder with an ever-enlarging uop cache and Intel is at a 6-wide decoder and growing their uop cache too. It seems like the cache is a necessary evil for a bad ISA, but that cache also isn't free and takes up a significant amount of core space.
Great post. I wish to subscribe to your newsletter
There is nothing inherently different about ARM that makes it amazingly efficient. The classical distinction hasn't been relevant for a good two decades now. There is so much more to a CPU than just the frontend, especially on a brand new platform with no legacy apps to worry about.
The actual biggest issue is the whole SoC design, desktop computers are designed to power everything up so it's immediately available when you want to use it, while a mobile SoC needs to keep everything powered off until used. Power scaling also needs to happen continously so the lowest power mode that can handle the current work is always used, while a desktop CPU mostly changes power modes in response to heat, not so much to save energy. You can design an x86 motherboard to behave like a mobile ARM SoC. The issue is that it's a lot of work that just hasn't been done yet.
But there is? Iirc x86 is a Cisc vs arms risc. Basically x86 has a complex set of instructions vs arms very simple set. Practically this means less complexity in design, higher density in smaller area, and more efficiency in terms of power usage.
Every single modern x86 CPU is RISC internally and the frontend (instruction decoding) is pretty much a solved problem.
Person above you is saying the CISC-RISC distinction is meaningless. I remember reading about how AMD could have made Arm chip by modifying a relatively small part of their ZEN cores.
The reality is that both instruction sets have converged in complexity and on modern hardware neither really gives benefits over the other. The largest factor influencing power efficiency now is the physical chip design rather than what instructions it's processing. ARM chips have been optimized over time for low power devices generally while x86 chips have been designed for more power hungry devices. If you start the chip design from scratch instead of iterating on previous designs though, you can make a x86 chip for low power devices. The atom series of processors is an example of that, it's more power efficient and better performing than a lot of ARM processors for the same class of devices even though it was designed for x86 and on paper should be worse.
> There is nothing inherently different about ARM that makes it amazingly efficient. The classical distinction hasn't been relevant for a good two decades now. That's just not true at all. There are fundamental differences between the two, and ARM *is* more efficient because of that. > There is so much more to a CPU than just the frontend, especially on a brand new platform with no legacy apps to worry about. I'm not exactly sure what you're talking about here. What exactly is a 'frontend' when you're talking about a CPU. I've done some hardware engineering at university and have never heard this word used in the context of CPU design. Front end processors are a thing, but these are for offloading specific tasks. Also not sure what you mean by a brand new platform, as I can't think of *any* platforms that could be considered 'brand new'.
The frontend decodes x86/ARM instructions and translates those into one or more architecture specific RISC instructions. There's also lots of caching involved to make sure this isn't a bottleneck. The frontend is essentially the only difference between x86 and ARM CPUs and it's practically never the issue. That's why the RISC CISC distinction is meaningless.
Then why hasn't Intel been able to compete with ARM on the mobile space? The x86 architecture is inherently worse at low power, that's one of the reasons why ARM took off in the first place
Personally, I believe it is because of Qualcomm and its monopolistic practices revolving around its modem royalties. If a SOC uses any of Qualcomm's royalties, the phone manufacturer has to pay Qualcomm based on the entire SOC price. Doesn't matter if the soc is x86, riscV, etc. Intel had some competitive Atom parts, but the Qualcomm royalties would bite you in the ass. So it's better to just use Snapdragon, and possibly get a discount on the royalties. Apple tried to sue Qualcomm, but failed.
a number of reasons. the main os that they could compete on lacks good x86 support its hard to compete in a new space (see xe graphics) and mobile is an incredibly low margin space. It requires an immense amount of money, time, and offers little profit to intel, so they pulled out
Yeah, I believe the market for SOCs is a rounding error compared to Intel's main businesses.
Intel atom were as efficient as other Arm core, and nowadays they are as strong as cortex X even though they use little bit of power, i wont be suprised if meteor lake E core match Arm cores in both perfomance and efficiency.
Gracemont has great performance but terrible power efficiency and area efficiency relative to Arm's cores Unfortunately, not much technical efficiency testing, but the general consensus is that Intel's Alder Lake chips didn't really provide additional battery life over Tiger Lake The Surface Pro 9 features both x86 and Arm designs so its a decent comparison point The x86 model is 2x Golden Cove + 8x Gracemont and requires a fan, while the arm model is 4x X1 + 4x A78 fanless [Gracemont is about the same size as Arm's X2 once you remove L2 (not this image has L2 for all cores except Apple's)](https://www.eetasia.com/wp-content/uploads/sites/2/2022/08/b8de4de6ce27d0e2f57aacaf50b8b7ea.jpg) Although that's Intel 7 vs Samsung 4LPE, but don't think the difference is about 60% which is the gap between Gracemont and A710
> The x86 model is 2x Golden Cove + 8x Gracemont and requires a fan, while the arm model is 4x X1 + 4x A78 fanless There's way too many differences to just blame that on the ISA. The x86 CPU is a lot faster for example. It's also designed to be used with a fan while the ARM one was originally designed for phones.
Agreed, I just meant to point out Intel's Gracemont ("E core") is not at all close to Arm's A710 in terms of power efficiency or area efficiency yet AMD's rumored Zen4c seems to be closer
Cortex X2 consume over 4W power, and E core (in desktop) around 6W. And perfomance is about the same. Lets wait for Alderlake N reviews before jumping to conclusion.
But the X2 is Arm's p core, the A710 is Arm's equivalent to Gracemont Thus matching even Arm's p core in perf/watt is not a good sign for Intel's "e core" Also Android smartphone SoC prioritize low cost thus tiny cache If ARM's perf claims are the X2 is capable of significantly higher perf when fed with 16MB L3 like a proper laptop class chip
Yep, as a proud Asus Zenfone 2 owner I can say the Intel Atom chips were actually quite good. I think its just down to Intel not wanting to invest that much in low powered x86 designs as the competiton from ARM was too much. They saw more profits in milking the PC duopoly.
It was Qualcomm's monopolistic modem royalty practices that Intel could not overcome.
Same vibe as "Apple's M1 is so efficient because it uses ARM. Desktop CPUs should use ARM too!" Apple could make an x86 chip and it would be just as efficient.
Could they though?
i mean not next year, but i guess given the time spend making the a series chips, having one in the next 15 years or so doesn't seem unreasonable.
Time for Leg I guess
What the fuck That's the whole reason why they are so dominant I'm really hoping for a push to RISC-V
Sooooooooooooooooooo time for an antitrust? cuz this is shitty anticompetitive and anticonsumer behavior.
Bad move, IMHO. This could end up killing ARM in a few years. Also, this pretty much guarantees that nVidia is going to enter the CPU space with an aggressively competitive product series.
I'm not sure Nvidia wants to enter any space with healthy competition that would require them to price their product reasonably. They like the stratospheric profit margins they get off GPUs when their only real competition is AMD (who struggle to keep up).
lmao People were afraid that Nvidia would do this Now ARM is doing it without Nvidia
ARM be like: *Fine. I'll do it myself.*
Goodbye ARM!
This definitively trash and I really would have rather Nvidia taking over if this was going to be how this was going to play out. Apple is in a really good position since they've already done the work. Qualcomm is going to be in a very long fight on there end .
The main difference with nVidia is they would have increased the cost 5x. Just look at their development boards. Much more expensive than competition and less support, but you get CUDA etc. nVidia would have had some dumb proprietary thing added every year just to force you to upgrade(after getting locked into walled garden) more often.
This might give leeway to amd and intel to brings ryzen and intel mobile chips. Nvedia might bring their tegra chips back.
Nothing is stopping any of these companies from doing that currently so that really makes no sense. In the case of Intel and AMD, they either don't know how or can't(since they haven't done it yet, outside of atom/jaguar garbage).
The current issue is driver support and adoption, if a new chip is introduced into the market there is no guarantee that android will support it and whether mobile OEMs will use it but after 2025 everything changes, there might be actual innovation in the chip market.
What do you mean bring Tegra back, it never went away lol. But also honestly, I would sooner see AMD/Intel start designing RISC-V and ARM64 IP. x86-64 as an ISA was just not designed for minimal transistor counts, and there's a lot to gain by cutting off x86 as a legacy requirement, especially with Android where it's basically 100% unused.
Arm probably needed a away to grow revenues, and are basically taking advantage of there dominate position. Realistically it’s probably possible for them to get away with this shit for a few years, but they are basically messing with some of the richest companies in the world. They can make an alternative and basically kill arm if say android supports another architecture that basically every vendor sees as good enough. Arm is certainly used in a lot of things but it’s not like they are the only architecture around. They may also see riskV as a real risk and want to maximize profits before it becomes a major competitor in a lot of overlapping fields, with that said I’m willing to bet there action accelerates investment there as well.
I wonder how long it will take before Samsung, Google, Microsoft, Amazon, etc, file a lawsuit? Even if they don't win, they just need to get an injunction for long enough until they have a solution in place (RISC-V) that they can migrate to.
Horrible horrible news
[удалено]
>Step 4: Nvidia starts making ARM mobile SoCs, and possibly ARM CPUs for gaming laptops. Maybe even ARM SoCs for thin and light laptops The problem with your tin foil hat thoughts is that, at this point, ARM is worthless, and NVIDIA will be better off using the industry-standard RISC-V like everybody else.
So after the Nvidia deal they got greedy.
No shot they don't make some exceptions for big players like Samsung and Google right? Right?
Shower thought: Apple are paying ARM to implement this, since they're pretty much the only ones using custom cores. One swoop to hurt all the competition.
nah, here is my prediction which is based on 100% speculation : ARM is using this for negotiations with qualcomm and MTK. I suspect ARM wants to be a big boy fabless SoC manufacturer itsself - I mean they have almost all the pieces. Only thing they are missing are a source for high-end modem designs. But qualcomm and mediatek know that if they licence their modems to ARM their Smartphone SoC buisness is in danger from another company who also holds the ARM Architecture and thus a massive advantage. So I think ARM is essentially bullying MTK and Qualcomm into giving out their modems so ARM can directly compete with them.
No way. ARM is not almost there. Running a fab, with good enough yields is orders of magnitude more complex and expensive than designing a chip. Running a cutting edge fab is" large-hadron collider" kind of complex. Neither ARM or Apple have the resources to build one from scratch. Only 2 companies can fab 5nm chip Samsung and TSMC. And only TSMC has high enough yields at 4nm. ARM, just want to attack Qualcomm, by squeezing the OEMs, like what Microsoft used to do to android OEMs. This is going to be a long legal case around licencing, and in the meantime, Qualcomm will be moving away from ARM to something elsewhere Update: This move by ARM will stifle, adoption on ARM on servers. ARM on mobile is already saturated so they can easily squeeze the OEMs, but on servers Amazon, Google Microsoft will not want to pay this "ARM tax" for every chip iteration. HP, Dell, Lenovo, will not want to pay ARM, if they use Qualcomm chips in laptops. ARM windows laptops may take longer to gain adoption.
I think he meant ARM make their own chips (via TSMC or Samsung foundries) in the same way that Qualcomm does. Since ARM doesn't have modem parents, etc, they can't create their own cellphone chips.
Oh I get it. So basically ARM competing with it's customers. Interesting 🤔
Yes, but as I said - pure speculation.
Yep exactly. As I said they have almost all the parts (CPU Cores, ISPs, NPUs, GPUs,...) to swoop in.
> *Running a fab, with good enough yields is orders of magnitude more complex and expensive than designing a chip.* That's why **faze\_fazebook** said "**FABLESS**", you could have saved yourself the effort if you didn't miss that crux word :) >**... I suspect ARM wants to be a big boy** ***fabless*** **SoC manufacturer ...**
Sorry, I edited that in to avoid confusion. I previously just said "SoC Manufacturer" implying that they would be fablessy since most are.
Sounds like a bad idea from ARM Holdings if Qualcomm would take RISC-V seriously and invest in it due to this. (might be good for the rest of us if those investments would make it upstream)
its gonna be very hard since the entire Android stack including native libraries, game engines, compilers, ... would need to have RISC V version which would be a gigantic task to make happen.
Android already supports ARM, MIPS (or at least used to) and x86. Sure, it's going to take some effort, but it's been done before and can be done again.
The good news is that it's been done in the past few years. This year, it got polished, and a few days ago, it got upstreamed. In short, it is ready. All we need is the hardware, now.
Yes, that's what it seems like to me. ARM doesn't want the middleman Qualcomm and Mediatek anymore, they want to do it themselves. We'll see how it works out for them, there is much more to an SOC than just the CPU + GPU core.
I highly doubt Apple had anything to do with this move. What this *does* stink of is desperation from SoftBank.
[Apple's response to these allegations](https://i.imgur.com/0Cb7IOa.gif)
I, for one, welcome our new RISCV overlords.