What’s the fate of K12/ARM at AMD?

[Daneden]

Let's wait and see. Iam looking forward for the next leaks regarding this topic.
For me it just doesnt make sense for AMD to compete with their own x86 chips.
But something semicustom is imageable.

 

[Gideon]

I can see them doing a custom SoC wit X1 and A78 but considering even Samsung and Qualcomm excited the custom ARM CPU business, I just don't see any reason for AMD to waste resources building competitive ARM cores to ARM's own offerings which are extremely good. IMO it would detract from their main CPU/GPU efforts.

 

[DrMrLordX]

Only real reason for AMD to mess with ARM today would be to enter the smartphone market, which I don't see as probable.

Either that, or they're going to pull an Apple on us and go ARM after Zen5. Not sure how they would get away with that, though.

 

[moinmoin]

Only real reason for AMD to mess with ARM today would be to enter the smartphone market, which I don't see as probable.

Without any decent modem IP? Doomed before the start already.

Either that, or they're going to pull an Apple on us and go ARM after Zen5. Not sure how they would get away with that, though.

It's not even "getting away with it". Why would AMD ever even consider exchanging its current x86 market share (where it enjoys the advantages of a de facto duopoly in a currently still dominant market) with some non-existing ARM market share?

High demand from semi custom business customers (who then need to worry about get all the missing IPs) could ensure AMD spending some R&D on ARM core optimizations of its own. Other than that I see no chance at all of that happening.

 

[HurleyBird]

Without any decent modem IP? Doomed before the start already.

Xilinx?

 

[moinmoin]

Xilinx?

Does it offer smartphone modems? I'm only aware of radios, i.e. those broadcasting antennas and base stations, not the piece in phones.

(And it's a little beside the point anyway since Xilinx is not part of AMD yet, until the end of next year at least.)

 

[dacostafilipe]

The idea with K12 and Skybridge is to have a modular system for ARM and x86.

Would it be viable to have ARM chiplets replace the x86 chiplets but keep the IO die and the platform the same? This could be interesting for light webservers where Zen cores are under-utilised.

And what about having both x86 and ARM on the same CPU? Could I run my Linux on x86 and create VMs running on the ARM cores, or the other way around?

 

[DrMrLordX]

Why would AMD ever even consider exchanging its current x86 market share (where it enjoys the advantages of a de facto duopoly in a currently still dominant market) with some non-existing ARM market share?

If they get stuck in a position where they can no longer iterate upon their x86 offerings (for whatever reason). And even then, that assumes that switching to an ARM underpinning would get them extra performance on the same node from the same design teams. If Intel continues to offer zero credible resistance, AMD will eventually be sitting at the top of the stack product-wise, meaning they could probably flog Zen5 for 2+ years until they could get new, non-x86 product out to keep things moving along. AMD may be able to continue iterating after Zen5, making the entire exercise unnecessary.

 

[moinmoin]

@DrMrLordX I can't imagine a situation where AMD is unable to continue iterating on x86 but still has something to offer (against more competition) for the ARM market. The underpinning is similar enough that if you're stuck with iterating on x86 switching to ARM won't help. While x86 is at a disadvantage to ARM, due to the rather exclusive access to the x86 market AMD enjoys it's in AMD's very interest to keep x86 ahead of ARM wherever possible instead designing any x86-killer itself.

 

[SarahKerrigan]

If AMD stays in x86-land, they have the benefit of decades of software momentum, and an ecosystem where they will only ever have the same two competitors (one of which has very limited volume, the other of which has been completely failing to execute for several years.)

If AMD goes ARM, and for some reason wishes to do custom microarchitectures, they're going up against Cortex/Neoverse, which has immense volumes and a developed customer ecosystem, as well as an actual history of delivering meaningful improvements on an annual basis. At that point they're also going up against specialized vendors (Fujitsu, arguably Apple), anyone who thinks they can make a good run with a custom microarchitecture (Nuvia, Phytium, whatever's left of Hisilicon), and every company that can afford a core license and a tapeout on a leading edge process.

From my perspective, AMD doing ARM makes no sense unless it becomes clear that x86 is becoming a legacy ecosystem - which is an outcome that would not be good for AMD. It exposes them to a much harsher competitive environment for few advantages.

But I've been wrong before.

 

[soresu]

If AMD stays in x86-land, they have the benefit of decades of software momentum, and an ecosystem where they will only ever have the same two competitors (one of which has very limited volume, the other of which has been completely failing to execute for several years.)

If you are referring to VIA/Zhaoxin remember that the China connection gives them potential access to a ginormous market.

Given the current political ruckus with Chinese trade the VIA numbers could see a huge uptick if the Chinese fabs really put their backs behind them.

 

[soresu]

If AMD goes ARM, and for some reason wishes to do custom microarchitectures, they're going up against Cortex/Neoverse

I'd be surprised if they didn't go semi custom with Cortex Xn/Neoverse Vx, unless nVidia purposefully cuts them off from that resource of course, which has always been one of my main reservations over the nVidia ARM sale.

 

[DrMrLordX]

@moinmoin

I would be surprised as well. I'm only considering edge cases here.

 

[DisEnchantment]

And what about having both x86 and ARM on the same CPU? Could I run my Linux on x86 and create VMs running on the ARM cores, or the other way around?

While we wait for true heterogeneous systems of the future, right now you can use QEMU for it. It is a pretty common workflow for a lot of deployments including ours.
You can run arm64 VMs with QEMU on amd64 platforms.
Or if you wanna go docker route, you can use qemu static multiarch images.

I'd be surprised if they didn't go semi custom with Cortex Xn/Neoverse Vx, unless nVidia purposefully cuts them off from that resource of course, which has always been one of my main reservations over the nVidia ARM sale.

I had an off the record conversation with our (ARM based SoCs) suppliers on this and I can say there is general unease. We are doing initial architecture work to target 2023/24 timeframe systems and I did ask (our non NV vendors) if we should be expecting something. Some of our vendors do have Plan Bs.
I bet they are watching the situation closely and also watching how RISC V evolves.

If NV has baseband ip, QC should be real worried. If NV start making server chips, the immediate pressure would be other ARM chip vendors. Because they are targeting the same customer base who are either having new workflows and/or have no code base that relies on x86's legacy.


For the rest (including us), who are still going to be relying on x86-64/amd64 build/packages for a little while longer....x86 legacy is a blessing and a curse.
The crazy part of all of this is that, most generic x86-64 SW has nothing targeting even baseline Skylake architecture!!!!.
The SW we are pulling from debian repositories don't target any modern x86 architecture.
On one hand it means you can run your SW on anything, on the other hand it means there is so much performance left on the table.
Same story on Windows. You can run binaries compiled from 15 years ago!!!
As long as you have ABI compatibility you are good to go.
Phoronix usually have good articles on this, worth reading.
Check Intel's Clear Linux vs the other distros. And generic x86-64 vs Skylake tuned tests.

Intel Clear Linux is the fastest distro out there.
However it is targetting ..... wait for it.... Sandy Bridge minimum!!

Windows store was supposed to be the solution to this(for apps using MS dev environment at least), with AOT triggering once on install. However it failed to take off.
Android handles this with JIT. But not being native means there is always something left on the table, but ART is improving a lot each release.
The AOSP however is still not properly tuned to the platform. With only HAL and /boot and /vendor SOs being compiled to target arch.

Going forward I am interested to see if IR is something that could solve this. Like how .NET 5 performs AOT from IR code.

 

[soresu]

However it is targetting ..... wait for it.... Sandy Bridge minimum!!

Doesn't surprise me.

The AVX512 fragmentation disaster is an example of Intel royally blasting their own feet off entirely of their own volition.

Not to mention the bad PR from spectre/meltdown.

 

[Tup3x]

If AMD stays in x86-land, they have the benefit of decades of software momentum, and an ecosystem where they will only ever have the same two competitors (one of which has very limited volume, the other of which has been completely failing to execute for several years.)

If AMD goes ARM, and for some reason wishes to do custom microarchitectures, they're going up against Cortex/Neoverse, which has immense volumes and a developed customer ecosystem, as well as an actual history of delivering meaningful improvements on an annual basis. At that point they're also going up against specialized vendors (Fujitsu, arguably Apple), anyone who thinks they can make a good run with a custom microarchitecture (Nuvia, Phytium, whatever's left of Hisilicon), and every company that can afford a core license and a tapeout on a leading edge process.

From my perspective, AMD doing ARM makes no sense unless it becomes clear that x86 is becoming a legacy ecosystem - which is an outcome that would not be good for AMD. It exposes them to a much harsher competitive environment for few advantages.

But I've been wrong before.

If some company suddenly made ARM desktop chip that annihilated competing x86 chips and would run emulated apps at competitive speed, I'd bet their roadmap might change rather quickly.

Personally I'd like to see ARM on desktop because it would break the duopoly.

 

[soresu]

Going forward I am interested to see if IR is something that could solve this. Like how .NET 5 performs AOT from IR code.

Intermediate representation?

I've read a bit into the development of Firefox's optimising JIT Ionmonkey and its use of intermediate representation, so I can understand your meaning if that is what you are talking about.

 

[Gideon]

Intermediate representation?

I've read a bit into the development of Firefox's optimising JIT Ionmonkey and its use of intermediate representation, so I can understand your meaning if that is what you are talking about.

btw, ionmonkey is a thing of the past, it's all Warp now (IR of course remains).

 

[DisEnchantment]

Intermediate representation?

I've read a bit into the development of Firefox's optimising JIT Ionmonkey and its use of intermediate representation, so I can understand your meaning if that is what you are talking about.

Yes it is or in MS terms IL (intermediate Language) code.
AOT (Ahead of Time) as envisioned with .NET5+ takes this further in that the CIL compiler (RyuJIT) produces native code on installation. instead of keeping the IL code as is. So the real binary being executed does not even need the CLR and the VM

AOT was there on Linux with mono and I was happy with the performance. Mono and .NET became NET 5 which is unified dotnet for everything, on Windows, iOS, macOS, Android, Linux.
Thing is though, this is not possible for most Operating Systems and system library programming.
But at least apps can make use of it.
Same concept like Shader compiling.

If we draw parallels to GPUs, it is like someone precompiled the shader code and distribute the binaries to be run on all HW , across GCN1-5, RDNA1-2 etc.
In order to make the same binary work, they compiled to the least common denominator.
So it is basically GCN1 code running on RDNA2. Thankfully GPUs do compilation of IR code and thus don't have the problem that x86 has to live with.
Intel Clear Linux is much faster than all the other distros out there simply because the baseline for compilation is Sandybridge.

 

[Daneden]

New leak regarding this topic.

I dont know how serious this is but sounds interesting

 

[NTMBK]

New leak regarding this topic.

I dont know how serious this is but sounds interesting

Is there a written version of this somewhere?

 

[Daneden]

Is there a written version of this somewhere?

Not that I know. I found it on reddit

https://www.reddit.com/r/AMD_Stock/comments/kszowi

 

[LightningZ71]

Referencing the above video, it is explaining that there are rumor-tweets out there claiming that the Exynos 2100 was assisted in development on both the gpu AND the cpu side by AMD and that means it has better than expected performance (grains of salt needed). Also, it expands a tiny bit on speculation that AMD is doing a full colab with Samsung on their next gen mobile SOC to have RDNA2 (or some subset of it) as the core of the GPU portion, and that it's ahead of schedule with a possible release to mass production before the end of the year. There is further speculation that there will be a gaming SOC released by Samsung as well, which will power some sort of console (be it mobile or stb).

 

[moinmoin]

Is there a written version of this somewhere?

Subtitles work fine on that video.

TLDW:
Samsung is "super duper confident" about Exynos 2100. Even though it doesn't include RDNA IP yet, reason is rumored to be AMD's involvement in fine tuning both CPU and GPU. The result is apparently competitive with Apple's silicon.

My comment:
If true this sounds more like some semi-custom project rather than a straight IP licensing (which referred to RDNA, which isn't involved here yet). Aside it being a rumor anyway we also don't know if that CPU fine tuning refers to AMD adding some K12 IP of its own or just refers to AMD excellent knowledge regarding optimizing silicon to specific nodes (as the development from VII, Zen 2/RDNA to Zen 3/RDNA 2 on TSMC's N7 has shown). Posting this in this thread is brave @Daneden

 

[moinmoin]

I'm allowing myself to resurrect this thread since now in Xlinix and Pensando AMD does own two ARM shops where it would make sense to merge all the ARM expertise, whatever is left of K12 respectively the knowledge and staff related to it.

For that matter Jim Keller recently said K12 was "stupidly cancelled".