Discussion AMD's Future APU Gone ARM?

[NostaSeronx]

Is this worth $2499? https://www.crowdsupply.com/milk-v/milk-v-pioneer#products

It is cheaper than AMD's Seattle (4-core Cortex-A57) DevKit by $500.

By 2016, the same configuration dropped to $599 in the Softiron Overdrive 1000. Which never released I think because the board manufacturer switched to HiKey 960 instead.

The one to watch is actually the SG2380, which is $120 after "【Pre-order】Milk-V Oasis - 16 Core RISC-V Desktop Coupon Code" and should be $150? w/o the "20%" coupon. Which is cross-compatible with RVA22 <-> RVA23 <-> RVA24. The chip still has awhile to be physically available allowing it to get RVA23 and OS-A23 Common in. OS-A Common: "The OS-A platform specifies a category of rich-OS platforms that support operating systems like Linux, FreeBSD, Windows and more" Which is why it is likely the platform to develop generic-image drivers on Windows for at least Imgtec/Radeon GPUs.

 

[soresu]

AMD given the timeframe is more likely to make RISC-V chips.

Given the current ecosystem RV just isn't a viable path for mass market computer SoCs in the short term outside of uses within other products like microcontrollers.

There's more to the equation of economic viability than just the performance of the core being competitive with current x86/64 and ARM options - it also needs to have a built in software base first, so there's a serious chicken and the egg problem to solve before you talk about AMD or nVidia going down that road.

ARM has only just gotten to the point of true viability for ARM Mac after several years and RISC-V hasn't even begun to start in the realms of serious software penetration - even dav1d only just got its first RV optimisations with the very latest release a few days ago

Even in the unlikely event that ARM as a popular use ISA does go bellyup in fantastic fashion AMD can still keep going in the x86/64 market anyway, and as nVidia does pretty well from selling mostly just GPUs already it wouldn't be that much of a gut punch to them either.

 

[igor_kavinski]

From 2019: https://riscv.org/wp-content/upload...-Suite-What-is-the-Cost-of-ISA-Simplicity.pdf



Smaller code size is indicative of good ISA? If so, RV isn't far behind ARM.

 

[SarahKerrigan]

From 2019: https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Code-Size-of-RISC-V-versus-ARM-using-the-Embench™-0.5-Benchmark-Suite-What-is-the-Cost-of-ISA-Simplicity.pdf

View attachment 94388

Smaller code size is indicative of good ISA? If so, RV isn't far behind ARM.

First - lower size is better, but so is lower dynamic instruction count.

Second - that's comparing against ARMv7 with Thumb2. ARM64 is a different ISA.

Third - I'd advise looking at Qualcomm's more recent and relevant slides on this subject, especially the last one of their presentation.

RV is not a great ISA.

 

[NostaSeronx]

Given the current ecosystem RV just isn't a viable path for mass market computer SoCs in the short term outside of uses within other products like microcontrollers.

There's more to the equation of economic viability than just the performance of the core being competitive with current x86/64 and ARM options - it also needs to have a built in software base first, so there's a serious chicken and the egg problem to solve before you talk about AMD or nVidia going down that road.

ARM has only just gotten to the point of true viability for ARM Mac after several years and RISC-V hasn't even begun to start in the realms of serious software penetration - even dav1d only just got its first RV optimisations with the very latest release a few days ago

Even in the unlikely event that ARM as a popular use ISA does go bellyup in fantastic fashion AMD can still keep going in the x86/64 market anyway, and as nVidia does pretty well from selling mostly just GPUs already it wouldn't be that much of a gut punch to them either.

Short term? "as soon as 2025" is basically a minimum speculative. Which means if it is viable it only needs the chips to launch in December 2025. Going further the Microsoft Next-Gen console is even further out to CY2028, lowest requirement: December 2028.

AMD isn't going to be first into the market. SiFive IP - Ventana IP - Tenstorrent IP then Rivos IP and Akeana IP will be first of the west. Much like T-head (C-cores), SOPHGO (RXU cores), CAS XiangShan cores, Huawei Taishan (Bristol RISC-V cores), etc for the east.

By the time AMD gets out a RISC-V core. All the work would be done.

From 2019: https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Code-Size-of-RISC-V-versus-ARM-using-the-Embench™-0.5-Benchmark-Suite-What-is-the-Cost-of-ISA-Simplicity.pdf

Smaller code size is indicative of good ISA? If so, RV isn't far behind ARM.

Debunking CISC vs RISC code density – Bits'n'Bites

www.bitsnbites.eu

Just note that it is just with the C-extension. Where RVV greatly reduces code density and dynamic instructions: VLEN=64 equals VLEN=128 LMUL=1/2 && VLEN=512 LMUL=1/8 && P-ext(not-ratified-not-frozen-in-rework-from-scratch). Which is why just C has higher instruction count, as it is doing SIMD work on Scalars.

 

[igor_kavinski]

Third - I'd advise looking at Qualcomm's more recent and relevant slides on this subject, especially the last one of their presentation.

Link?

 

[SarahKerrigan]

Link?

https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%20case%20to%20remove%20the%20C%20extension%20from%20app%20profiles,%20part%202%20-%20Profiles%20TG%2020231005.pdf

 

[igor_kavinski]

Debunking CISC vs RISC code density – Bits'n'Bites

www.bitsnbites.eu

Very informative. Thanks!

 

[igor_kavinski]

https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%20case%20to%20remove%20the%20C%20extension%20from%20app%20profiles,%20part%202%20-%20Profiles%20TG%2020231005.pdf

That's pretty hardcore for someone with no assembly experience (ME!).

So QC is proposing ZNEW instruction encoding? What are the chances that the other players will agree? If everyone does agree, will this end the great ISA debate?

 

[SarahKerrigan]

That's pretty hardcore for someone with no assembly experience (ME!).

So QC is proposing ZNEW instruction encoding? What are the chances that the other players will agree? If everyone does agree, will this end the great ISA debate?

They proposed a couple of dozen new ops to bring RV up to feature parity with ARM64. At least according to Qualcomm, they would result in RV having moderately lower dynamic instruction count than ARM64. It would mean sacrificing the variable-length extension, at least in the applications profile.

There's no "great ISA debate." There are economic and political factors around ISA selection, and much smaller technical factors. If RV was graded purely by the latter, it would not have acquired the momentum it has.

 

[NostaSeronx]

That's pretty hardcore for someone with no assembly experience (ME!).

So QC is proposing ZNEW instruction encoding? What are the chances that the other players will agree? If everyone does agree, will this end the great ISA debate?

The BoD came in and agreed with SiFive (and others against Znew): https://lists.riscv.org/g/tech-profiles/topic/slides_on_retaining_ialign_16/101922590
"The BoD has sent a strong message that unless there is something catastrophic (e.g. a security issue -- which we have none), that they want RVI members to honor the bond of RVI's word for items like this that are published as mandatory in profiles."

SiFive, Ventana, Tenstorrent are likely already built for maximizing the C extension.


Overall, it isn't an issue for RISC-V getting out and beating ARM64/AMD64.
RV64G = Bad density, instruction count, etc.
RV64GC = Good density, etc. Bad instruction count.
RV64GCBV = Good density, etc. Good instruction count.

P670's most important instructions on clamping down sizes across encoding/compression/compute/etc:
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+c"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zba"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zbb"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zbs"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+v"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zvbb"
// MCPU-SIFIVE-P670-SAME: "-target-feature" "+zvbc"

Want to re-iterate general pathing on prior post:
2024 -- Sophgo's SG2380 => First SoC hardware with instructions that stretch from RVA22(Major) to RVA23(Minor) to RVA24(Major).
Baseline requirements for Android and Windows.

2024+/2025 -- Next group would be Tenstorrent/Ventana with Akeana/Rivos. Only Ventana has disclosed SoC plans with Imgtec. While, Tenstorrent is an owner of CPU IP, not a producer of SoC IP. So, only LG/Samsung Ascalon-based SoCs will be the avenue of those products. Akeana is likely to be more aggressive than Tenstorrent in licensing into SoCs. While Rivos might follow Ventana with partnering with a GPU IP and building SoCs themselves.

2025+/2026 --Then, finally AMD will deploy RISC-V cores.
Feature complete goal for Windows and other OSes will be achieved by this point.

 

[igor_kavinski]

Any thoughts on Tenstorrent Sonic Boom?

 

[camel-cdr]

They proposed a couple of dozen new ops to bring RV up to feature parity with ARM64. At least according to Qualcomm, they would result in RV having moderately lower dynamic instruction count than ARM64. It would mean sacrificing the variable-length extension, at least in the applications profile.

There's no "great ISA debate." There are economic and political factors around ISA selection, and much smaller technical factors. If RV was graded purely by the latter, it would not have acquired the momentum it has.

For anybody that is interested, you can watch the meeting recordings here by scrolling down here: https://lists.riscv.org/g/tech-profiles/topics

My takeaway from watching them is that:

1. All parties agreed, that both options are valid for developing application class cores.

2. C doesn't increase decode complexity by that much, because you need an uop cache anyway, and you can just expand compressed instructions to the equivalent non-compressed ones.

3. The most basic disagreement was how to split up the encoding space and how that will evolve in the future (the added instructions were to compensate the missing C, and not that relevant to the discussion). One faction wanted 32-bit instructions and 64-bit aligned 64-bit instructions, while the other one wanted to preserve the status quo, so 16-bit compressed, 32-bit, and possible expansions to 48 and 64-bits. One talking point was future matrix extensions or vector instructions with encoded vtype. Without C you could probably fit one of those into 32-bit instructions, but that would eat a lot of encoding space again, and other extensions would require 64-bit aligned 64-bit instructions, which would increase code size. With C you might be able to fit it into 48-bit instructions, but you might also run out of those and also need to go to 64-bit instructions.

4. Going without C might be a bit better for high performance cores, but the cost on the software ecosystem and binary app marked would be large. The idea was to collect some data on it, but BoD stepped in with a decision. This is imo quite understandable, as the pros and cons of C had obviously been debated before already, and we've seen feedback that implementers didn't really struggle with it.

There was the rumor that Rivos and Qualcomm, where against the C extension, so they could easier repurpose their custom arm designs to risc-v, but idk how feasible that would've been anyways.

 

[igor_kavinski]

Welcome, @oj002 !!!

A most excellent first post!

 

[naukkis]

First - lower size is better, but so is lower dynamic instruction count.

Second - that's comparing against ARMv7 with Thumb2. ARM64 is a different ISA.

Third - I'd advise looking at Qualcomm's more recent and relevant slides on this subject, especially the last one of their presentation.

RV is not a great ISA.

Qualcomm proposes basically to make Risc-V AAarch64. That makes sense if they just want to change their ARM64 hardware as easy as possible to Risc-V. But Risc-V is hardware-unrelated ISA and should stay so so there's absolutely no reason to accept those Qualcomm propositions. If Qualcomm thinks ARM is great they should stay with it - let others do their Risv-V implementations - where packet instructions are already widely used.

 

[igor_kavinski]

But Risc-V is hardware-unrelated ISA and should stay so so there's absolutely no reason to accept those Qualcomm propositions.

I guess QC thought it was worth a shot pulling wool over the eyes of other members

 

[Tigerick]

Wow, thanks for heated debate about Risc-V. I don't mind at all cause ARM itself is a RISC instruction sets.(Then what the hell is the difference?) Meanwhile, I am updating the frontpage to include more tables to support my speculations. As I learned more about ARM, I am more convinced AMD will move to ARM cores in the future...

Before that, I have to say Jim Keller is a god in CPU designer, period. There is no doubt and no person will argue with him about CPU design.....well, except in process node. Jim won't discuss the difference in the process node which is actually playing important role in iso-power. Take Apple's M2 and M3 for example, some said Apple don't change architecture of CPU core for years..However, by moving from N5P to N3B, Apple able to clock M3 to 4GHz within same power TDP, the result is more than 15% faster performance in single thread.

Meanwhile, AMD seems able to hit almost 3K points with their Zen4 at 170W TDP. 1T performance should be less prone to TDP, however what we see in Ryzen 7840U, the points have dropped to 2.1K in Geekbench 6. Clearly, Zen 4 core is not as power efficient in APU, I believe this will improve with Zen5 but by how much? That's why I am more interested in upcoming Strix Point cause STX might be last monolithic x86 SoC build by AMD..

1T still remain most important performance metric for all CPU. The point comes with combination of architecture and clock speed. As you see on difference between Cortex-X3 and X4, ARM has changed the CPU design quite a lot, but the point only increases slightly in Geekbench. This is going to change in upcoming Cortex-X5 due to N3E process, we don't know final clock speed of D9400. It should clock near to 4GHz and it will bump 1T to around 2700 points. And here comes the tipping points of ARM for mobile PC, can you imagine the performance of SoC if they are not thermal constrained? Especially with upcoming LPDDR6, AMD has every reason to move to ARM core.

Beside performance point, let's compare die size of X-Elite and upcoming Strix Point. X-Elite is having around 171mm2 and STX should come with 225mm2. Both SoC are manufactured by TSMC's N4P and they are both offering similar CPU core counts. AMD should offer better GPU performance, does that make difference to OEMs? If Qualcomm and AMD are maintaining same profit margin, then AMD has to price STX higher than X-Elite. Do you think which SoC OEMs will choose in the long run? ARM cores are going to perform better per watt than x86 with smaller die area, this is the future AMD is facing...

FYI, Microsoft's SQ1 is based on 8cx and SQ2 is based on 8cx G2. If Microsoft uses "custom" ARM SoC from AMD in upcoming Surface X, so tell me which SoC is AMD going to use?

 

[Thibsie]

AMD may move to ARM although it is way too early for that IMO.
The point I don't agree with is the fact that AMD APU will go away from monolithic. I suspect this reverse is true, desktop CPUs will go back to monolithic and be a by product of mobile, rather than a by product of Epyc.

 

[Tigerick]

AMD's lineup after Venice, no more Zen7 ???

If anyone is still reluctant to believe AMD's future APU is based on ARM core, here comes more scary future for you:

Venice is upcoming AMD's EPYC server platform after Turin. Venice platform could support up to 256 core counts as shown in the mockup picture from MLID:


Zen 6C is going to be manufactured by TSMC's N2 process, the most advanced process TSMC is offering in
2026. AMD have to opt for it cause with doubling cores, TDP will hit higher. Turin platform supporting 128-core (with 16 pcs tCPU) have 600W TDP per socket. I think Venice platform with 256-core would be the most core counts AMD going to offer for x86 server platform. How about lineup after Venice?

Remember MLID mentioned there is no Zen 7 in the roadmap? At first, I thought maybe too early for future Zen to appear in the lineup. Now I am thinking AMD will move whole Zen lineup to ARM platform in the near future starting from FY2026.

Let me show you Ampere Computing's latest cloud native server CPU: AmpereOne with 192-core CPU that is built by TSMC's N5 process:-



The CPU is a monolithic die with 192-core (shown is A160-30 means 160 cores @ 3GHz) at 350W TDP. Can you imagine if AMD choose to use ARM core with N2 process, how many cores AMD able to fit in within 600W TDP? That's the reason AMD will switch to ARM cores in the future, same as client SoC.

Like Ampere, AMD should embrace an Arm architecture license which offers greater freedom. You may ask how about OS support? Qualcomm and AMD have entered ARM server CPU before, without OS support, what is the point?

Well, we should be hearing Windows Server for ARM pretty soon...

Unlike Apple, AMD would most likely be maintaining two product lineups in the future. However, AMD will keep upgrading and expanding ARM platforms. The x86 platform will not be dead, but should I said will slowly become "Legacy" in the future...

Above predictions won't happen overnight, we should be hearing more in coming years. Treat this as rumor if you like. Have a nice weekend, everyone !

 

[FlameTail]

Idk which video it was, but once MLID was mumbling something about post-Zen 6 AMD cores.

He said AMD is developing separate Big, medium and little cores. That sounds very similar to the current ARM approach with Cortex X, Cortex A7xx and Cortex A5xx.

 

[StefanR5R]

X-Elite is having around 171mm2 and STX should come with 225mm2. [...] If Qualcomm and AMD are maintaining same profit margin, then AMD has to price STX higher than X-Elite.

How much of these SoC sizes is comprised of a) CPU cores, b) within the cores, decoders¹?

Do you think which SoC OEMs will choose in the long run?

The ones which sell well to their customers.

ARM cores are going to perform better per watt than x86

How much of task energy is spent on decoding¹?

Turin platform supporting 128-core (with 16 pcs tCPU) have 600W TDP per socket.

AFAIK the rumors have been adjusted to 500 W cTDP_high for Turin and Turin dense already a while ago.

________
¹) The differences go actually further than just the decoding. The memory model is different too. But I haven't delved deep enough into this subject matter to ask the right questions how this may impact SoC sizes and task energy.

 

[NTMBK]

Idk which video it was, but once MLID was mumbling something about post-Zen 6 AMD cores.

He said AMD is developing separate Big, medium and little cores. That sounds very similar to the current ARM approach with Cortex X, Cortex A7xx and Cortex A5xx.

MLID says a lot of things. Very few of them turn out to be accurate.

 

[NostaSeronx]

That's the reason AMD will switch to ARM cores in the future, same as client SoC.

Alastor D6 (Zen4 target core) has this partition:

The current iteration supposedly can support THREE of these Aegis clusters on a single package. 384-core, 12xDDR5, >300W, <400 mm2[CPU Chiplets only], etc.

 

[yuri69]

Let me show you Ampere Computing's latest cloud native server CPU: AmpereOne with 192-core CPU that is built by TSMC's N5 process:

AmpereOne has been reportedly sampling since May 2022, launched in May 2023, and agot dopted by Oracle in Sep 2023. Yet, AFAIK there are no 3rd party reviews available nor is the Oracle A2 instance.

AMD stated they are ready to adopt ARM at any time it makes sense.

ZenX branding will surely stop at some point. I mean, the brand will be nearly 10 yo with Zen 6.

 

[QuickyDuck]

ARM or RISC-V doesn't inherently bring you power efficiency.

Apple cpus are superior simple because they are well designed and well made; ISA doesn't make that much of a lift.

I believe AMD will make arm cpus when customers demand it.

Given how modular ZEN architecture is, AMD could reuse most of the parts with minimal manpower and time.