Discussion The end of Qualcomm's Nuvia dreams?

[eek2121]

Why do you think so?

This seems like ARM is finally beginning to reap its position as the main engine behind the mobile revolution and soon-to-be server-dominance.

Qualcomm doesn't have to make ARM chips...

Depends on the horizon.

Would RISCV make an impact on ARM's mobile, server, laptop market in the next 5 years? Absolutely not. Apple hasn't even finished transitioning to ARM yet after spending billions and many years in both hardware design and software compatibility. Microsoft is spending hundreds of millions or even billions to make Windows ARM and x86 emulation. Android is completely fragmented. Amazon is all in on ARM servers with their Graviton.

Apple = force desktop/laptop software to build ARM versions
Amazon = force server software to build ARM versions
Google/Apple = force mobile software to build ARM versions

No one is forcing RISCV onto software makers.

In 10 years? Maybe.

In the next 5 years, RISCV isn't going to do that much except in specialized situations. The only caveat to this prediction is that maybe Chinese companies will push RISCV hard.

But if Qualcomm gets its way with Nuvia, ARM's business might suffer as soon as 2024. That's 1 year from now. I think what ARM is doing is smart and its only option.

Yes, RISC-V can absolutely overtake ARM in the next 5 years. There are 3 high performance and multiple low power chips in development. Latest versions of Linux have support mainlined and Google has positioned RISC-V to be a prime part of android.

If ARM alienates Qualcomm, ARM dominance in the mobile sector will die practically overnight. Qualcomm + Apple would be ARM's 2 biggest customers.

Remember that ANYONE can build a RISC-V chip.

Disclaimer: I own 2 different RISC-V platforms and I'm looking at purchasing another when it becomes available.

 

[soresu]

Google has positioned RISC-V to be a prime part of android

You are missing the part where ARM64 has such a huge installed base of software already.

This is precisely why Intel had such an unwinnable uphill battle getting x86 into the Android market to a significant degree.

Sure lots of stuff made for Java VM or Dart/Flutter transpiler can work on whatever has a well made backend, but that does nothing for the gamut of native ARM64 code out there in the Play Store which will need to use some kind of binary translation unless Google intends to mandate multi ISA apps which seems unlikely.

I could see a possible future where Google transitions Android/Fuchsia to RISC-V and outlines an end date for supporting native ARM64, but I severely doubt that this would happen any time soon unless things in the ARM world truly go nuclear.

 

[soresu]

If ARM alienates Qualcomm, ARM dominance in the mobile sector will die practically overnight

As much as many Android OEMs currently have relationships with Qualcomm, don't imagine for a second that they wouldn't ditch them for Mediatek if they had to.

It's not like QC don't have their own history of bad monopolistic practices that Mediatek and others like Broadcom would exploit for gain if QC just decided to pull a hail mary and go their own way.

 

[Doug S]

As much as many Android OEMs currently have relationships with Qualcomm, don't imagine for a second that they wouldn't ditch them for Mediatek if they had to.

Its a chicken and egg situation. Who is going to invest millions to internally develop and market RISC-V Androids when there are no RISC-V binaries in the app store? What developers are going to build, test and support RISC-V versions of their apps without a significant installed base of RISC-V Androids? Most importantly, consider the big apps that the majority of people buying a phone expect to have available: Facebook, TikTok, WhatsApp, GMail, Instagram, Minecraft, whatever... If they buy a RISC-V Android and find out whichever one of those heavy hitter apps they consider a must have is not available, that phone is getting returned the next day. When the next fad app pops up, who wants to be the loser left behind from what all their friends are talking about because the small time developer didn't have the resources to do a RISC-V version? Sure he belatedly follows up with the RISC-V port three months later, after the fad has passed and no one cares anymore.

So maybe someone or several someones out there are developing a "high performance" RISC-V (we'll have to see what that means in context with leading Android SoCs or if they just mean "better than the crappy performance of current RISC-V implementations) but where's the cellular modem coming from? Apple is the only company buying discrete modems, and they buy in massive volumes. If you can't commit to Apple level volumes because you don't know how well your RISC-V phone will sell, any savings from using RISC-V instead of ARM will be wiped out by the higher cost for the modem.

What about chip designers that have their own modems like Mediatek, they could do a RISC-V SoC with their modem included, right? That's hundreds of millions in investment, and they still have that chicken and egg problem for their customers who will be reluctant to design RISC-V Androids until the apps are there. They aren't going to invest that money to design the integrated RISC-V SoC unless their customers commit to ordering up front; they won't do it just because customers say "we'd like to have this as an option but I'm not going to promise to buy more than the token amount necessary for in-house testing".

I think the only way RISC-V becomes a real platform on Android is if Google mandates fat binaries that include RISC-V after some date. But why would they do that? Why is their incentive to force RISC-V as an alternative? It isn't like they share in any of the savings if companies can shave a buck off their BOM using RISC-V instead of ARM.

 

[moinmoin]

Personally I think RISC-V making an impact in the mid term is much more likely in the DCs than in the mobile market. The former while slow is more flexible regarding software. Due to the widespread use of open source it's closer to a solved problem.

In the mobile market I do think Google has an interest in not being seen as being locked to one ISA, so they'll at least work against the impression that RISC-V entry is being hampered by lack of support by Android. I'm not even sure why forcing universal binaries would be a disadvantage. It's actually a competitive advantage against all the other openly usable Android stores. (Conversely some Android store say by Amazon or Epic Games etc. could push ahead doing that step first, putting pressure on Google.)

In any case if Arm is so adamant to have its licensees stop working on custom ARM cores you can bet at least some of the work on custom cores then will continue on non-ARM ISAs instead. So changes like this thread is about will only speed up this (in the long term imo unavoidable) development. Arm is haphazardly creating competitors out of former partners with such moves.

 

[eek2121]

As much as many Android OEMs currently have relationships with Qualcomm, don't imagine for a second that they wouldn't ditch them for Mediatek if they had to.

It's not like QC don't have their own history of bad monopolistic practices that Mediatek and others like Broadcom would exploit for gain if QC just decided to pull a hail mary and go their own way.

Its a chicken and egg situation. Who is going to invest millions to internally develop and market RISC-V Androids when there are no RISC-V binaries in the app store? What developers are going to build, test and support RISC-V versions of their apps without a significant installed base of RISC-V Androids? Most importantly, consider the big apps that the majority of people buying a phone expect to have available: Facebook, TikTok, WhatsApp, GMail, Instagram, Minecraft, whatever... If they buy a RISC-V Android and find out whichever one of those heavy hitter apps they consider a must have is not available, that phone is getting returned the next day. When the next fad app pops up, who wants to be the loser left behind from what all their friends are talking about because the small time developer didn't have the resources to do a RISC-V version? Sure he belatedly follows up with the RISC-V port three months later, after the fad has passed and no one cares anymore.

So maybe someone or several someones out there are developing a "high performance" RISC-V (we'll have to see what that means in context with leading Android SoCs or if they just mean "better than the crappy performance of current RISC-V implementations) but where's the cellular modem coming from? Apple is the only company buying discrete modems, and they buy in massive volumes. If you can't commit to Apple level volumes because you don't know how well your RISC-V phone will sell, any savings from using RISC-V instead of ARM will be wiped out by the higher cost for the modem.

What about chip designers that have their own modems like Mediatek, they could do a RISC-V SoC with their modem included, right? That's hundreds of millions in investment, and they still have that chicken and egg problem for their customers who will be reluctant to design RISC-V Androids until the apps are there. They aren't going to invest that money to design the integrated RISC-V SoC unless their customers commit to ordering up front; they won't do it just because customers say "we'd like to have this as an option but I'm not going to promise to buy more than the token amount necessary for in-house testing".

I think the only way RISC-V becomes a real platform on Android is if Google mandates fat binaries that include RISC-V after some date. But why would they do that? Why is their incentive to force RISC-V as an alternative? It isn't like they share in any of the savings if companies can shave a buck off their BOM using RISC-V instead of ARM.

I feel like most of you folks don’t understand how Android apps work at all. Once Google provides the tooling, most Android apps will work without modification.

You can even install Android on your x86 PC and run apps if you wanted.

 

[Doug S]

I feel like most of you folks don’t understand how Android apps work at all. Once Google provides the tooling, most Android apps will work without modification.

You can even install Android on your x86 PC and run apps if you wanted.

I feel like you don't understand how software development works at all. No developer is going to trust that their app will "just work" on a different architecture without testing it and its existence (if the compiler starts spitting out fat binaries by default) doesn't mean they will care if it is reported to not work correctly - at least not until there are enough RISC-V Android phones for them think it is worth bothering with.

If someone tries to run their Disney+ app on their Windows PC and it doesn't work right and they contact Disney what do you think they will say? "Sorry we don't support running our app on Windows, you can use our website to access Disney+" is what they'd probably say.

 

[Schmide]

Android apps, the SDK, are basically java; however, they provide a NDK for native code. So depending on the flavor of APP it can go either way.

 

[Doug S]

Android apps, the SDK, are basically java; however, they provide a NDK for native code. So depending on the flavor of APP it can go either way.

I was under the impression almost all Android apps were native code these days. Are there any leading apps (with more than 10 million installs let's say) that are solely Java or Kotlin or whatever they're calling it these days.

 

[soresu]

I was under the impression almost all Android apps were native code these days. Are there any leading apps (with more than 10 million installs let's say) that are solely Java or Kotlin or whatever they're calling it these days.

Kotlin is not Java itself as I understand it - it is used more like a compile to Java language, kind of like how Dart is mostly used to compile to Javascript these days.

Either way I doubt that anywhere near all the Play Store apps are predominantly native code.

Many may use common libraries like FFMPEG or dav1d with native code, but such things often have plenty of assembly for other ISAs, mostly x86 for the moment.

 

[Schmide]

I was under the impression almost all Android apps were native code these days. Are there any leading apps (with more than 10 million installs let's say) that are solely Java or Kotlin or whatever they're calling it these days.

I don't know? But if you think about it these days everything runs with a library. Qt, webGL, unity, source, wtWidgets, electron, etc It takes a big player to make a native library.

I've only researched the pathways one could take to produce an app, not what all the cool kids are doing these days.

Guessing. Most of the apps in number are SDK based with a minority in number porting custom libs for native execution.

 

[mikegg]

I feel like you don't understand how software development works at all. No developer is going to trust that their app will "just work" on a different architecture without testing it and its existence (if the compiler starts spitting out fat binaries by default) doesn't mean they will care if it is reported to not work correctly - at least not until there are enough RISC-V Android phones for them think it is worth bothering with.

If someone tries to run their Disney+ app on their Windows PC and it doesn't work right and they contact Disney what do you think they will say? "Sorry we don't support running our app on Windows, you can use our website to access Disney+" is what they'd probably say.

That's exactly why Apple does not automatically make every iPad app available to macOS despite the fact that both are using Apple Silicon chips now. Apple requires developers to explicitly tick the "allow my iPad app to be available in macOS app store" box if they want their iPad app to be available on macOS.

 

[Doug S]

That's exactly why Apple does not automatically make every iPad app available to macOS despite the fact that both are using Apple Silicon chips now. Apple requires developers to explicitly tick the "allow my iPad app to be available in macOS app store" box if they want their iPad app to be available on macOS.

Apple is always very careful, but things should "just work" when they use the same CPUs and the exact same libraries are (presumably) available on the Mac. Still, they don't have the same hardware (i.e. touchscreen) so things have to work a little different even if there won't be any ISA level incompatibilities due to different compilers or software translation. That's probably why Apple does it this way.

Plus they want to give developers a choice - some may want to charge a different price for the Mac version rather than having the iPad version be available there...

 

[mikegg]

By that logic everyone would want an iphone and not android anymore because iphone performs much better.

And many do. However, the iPhone is completely different from Android phones in every way, including the SoC.

Therefore, if Nuvia is performing significantly better than anything else Samsung or Mediatek can make, then Nuvia will take the highend completely. Mediatek and Samsung will still sell some, but they'll be relegated to low end. Nuvia can fill the stack from high to low and command premium prices in each segment.

 

[mikegg]

Regardless of how the license situation works out Qualcomm is still a huge licensee of ARM IP in general from the sheer quantity of product in the market that uses Qualcomm ARM SoCs.

No amount of shifting to custom cores from QC is going to put ARM Ltd in a grave, simply because every sale QC makes is still money in SoftBank/ARM's coffers one way or another.

At worst it might stymy funding for future Cortex X µArch development if Mediatek, Samsung and perhaps also Google are not enough together to take up the slack in high volume licensees of those higher performance designs.

Also keep in mind that some Neoverse customers are funding that development to a degree, as Neoverse V cores are based on the same µArch design work for Cortex X, just as Neoverse N cores are based on big Cortex Axxx.

At this point it's also way too early to hail the crow of the Nuvia's Phoenix core when it was announced so far back, and Cortex X µArchs have come on no small way since.

I'm certainly interested to see Oryon perform and to get me a perf heavy ARM box, but Qualcomm would not be the first big hitter to buy a company for a new custom core design only to be less than satisfied with its performance in such a competitive marketplace.

When I say "dig ARM's grave", I mean end ARM's ability to compete in the highend, which is their most lucrative business.

 

[mikegg]

Couldn't have said it better myself.

A point to add to that:

Enthusiasts (aka our wizened community of tech connisseurs 🧙‍♂️) often forget that the average naive mark who walks into an O2/EE/Vodafone/Verizon/etc/etc outlet store and into the jaws of their sales personnel often don't know one phone manufacturer from another very well, let alone what SoC runs in it to any significant degree, or who designed it.

Both of you misunderstand.

It's well known that low-end phones where people walk into the store and buy whatever has extremely low margins - sometimes selling at a loss.

If Nuvia takes the highend compeletely, stock ARM designs will not be able to compete. Mediatek uses stock ARM designs. And once Nuvia takes the highend, it will fill the stack and compete in the mid and low end as well. This will squeeze ARM's profit and its ability to attract talent to design highend cores for Mediatek and other vendors.

 

[soresu]

If Nuvia takes the highend compeletely

For that to happen the perf delta would have to be sizable and the power draw delta comparably bad, which I have serious doubts about at this point.

The last time I saw any PR from Qualcomm/Nuvia about performance they did not even sound that bullish about it - they were talking about competitiveness with current and next year ARM hi end (I think before X3 was even announced) rather than Apple's, which didn't sound encouraging.

Keep in mind that when Phoenix was announced back in 2020 that ARM had just announced their first Cortex X µArch only a few months earlier.

2 core iterations later the X µArch had already jumped to a 6 wide design - I doubt that Nuvia or their new owners Qualcomm had accounted for such a fast design cadence when considering the investment risks.

We'll soon see from this years IP announcements what ARM has in store for 2024 - unlike last year there should be a full range of new cores for every segment, so June should be a very interesting month.

 

[soresu]

It's well known that low-end phones where people walk into the store and buy whatever has extremely low margins - sometimes selling at a loss.

Often it's not even about margins so much as what individual sales staff recommend, which is not necessarily standardised across stores - some may be purposefully pushing certain brands and encouraging their sales staff to follow that line, but many are probably just trying to make whatever sales they can.

 

[Doug S]

If Nuvia takes the highend compeletely

How do you see that ever happening? If people chose high end phones based solely on CPU performance everyone would be buying iPhones.

It is safe to assume that Qualcomm will not sell Nuvia core SoCs for discount prices, so there will still be a market for SoCs that may not perform as well CPU wise but are either cheaper, have other features (i.e. GPU etc.) that are better, or simply because of NIH (i.e. Samsung & Chinese OEMs aren't going to use Qualcomm SoCs for their entire worldside high end market)

Qualcomm may take the Android SoC performance crown, but they cannot take the entire Android high end market.

 

[Mopetar]

Yes, RISC-V can absolutely overtake ARM in the next 5 years. There are 3 high performance and multiple low power chips in development. Latest versions of Linux have support mainlined and Google has positioned RISC-V to be a prime part of android.

Anyone can build a RISC-V CPU without having to worry about licensing issues, but it's another thing entirely to build something that's actually worth a damn. Most of the companies producing ARM SoCs are licensing designs. Hiring a design team is expensive. Qualcomm spent $1.4 billion just to acquire the Nuvia team and they still are paying those people a lot of money every year.

A simple RISC-V core design isn't going to be too difficult, but building something that can reliably execute multiple instructions per clock cycle out of order becomes far more difficult. That's what makes Apple's CPUs so beastly. Building something capable of that kind of performance isn't trivial and it took Apple themselves several years to cultivate the capability to design those chips.

If China wants to crank out basic designs on older process nodes no one is going to be too bothered. It's probably fine for their domestic market where the emerging middle class would be fine with something low cost even if the performance isn't winning any awards. Apple's cores are overkill for a phone at this point. But the only thing they really compete on is price and no sane person is going to trust that their totalitarian despotic government didn't force the companies to add some kind of back door.

 

[dark zero]

How do you see that ever happening? If people chose high end phones based solely on CPU performance everyone would be buying iPhones.

It is safe to assume that Qualcomm will not sell Nuvia core SoCs for discount prices, so there will still be a market for SoCs that may not perform as well CPU wise but are either cheaper, have other features (i.e. GPU etc.) that are better, or simply because of NIH (i.e. Samsung & Chinese OEMs aren't going to use Qualcomm SoCs for their entire worldside high end market)

Qualcomm may take the Android SoC performance crown, but they cannot take the entire Android high end market.

And if they do, Apple at the end would be the leader since Software side they really shines.

 

[mikegg]

How do you see that ever happening? If people chose high end phones based solely on CPU performance everyone would be buying iPhones.

Android phone makers can't call their phones high end if they don't use a Nuvia chip that is 30% faster and provides longer battery life. In a scenario like this, the highest end Android phones must use Nuvia.

 

[NTMBK]

Android phone makers can't call their phones high end if they don't use a Nuvia chip that is 30% faster and provides longer battery life. In a scenario like this, the highest end Android phones must use Nuvia.

If it has a better screen, better camera, better AI accelerator etc then sure they can. A lot of things in phones are more important than CPU performance.

 

[mikegg]

If it has a better screen, better camera, better AI accelerator etc then sure they can. A lot of things in phones are more important than CPU performance.

Sure, but that doesn't make sense in practice. An Android high-end phone with a Nuvia chip that is 30% faster than other Android competition will have those things too. Hence, the Nuvia version will be called the defacto high end and will command the highest price in the Android world.

Also, keep in mind that Qualcomm sells to other vendors. They don't make their own phones. So if you're Xiaomi or Samsung or Oppo, you're going to want to buy Nuvia chips for your highest end phones, not Mediatek.

PS. I don't think it's correct to say "a lot of things" are more important than the SoC. The SoC is probably the most important thing along with the screen. So maybe one thing is more important than the SoC - not "a lot".

 

[NTMBK]

Sure, but that doesn't make sense in practice. An Android high-end phone with a Nuvia chip that is 30% faster than other Android competition will have those things too. Hence, the Nuvia version will be called the defacto high end and will command the highest price in the Android world.

Also, keep in mind that Qualcomm sells to other vendors. They don't make their own phones. So if you're Xiaomi or Samsung or Oppo, you're going to want to buy Nuvia chips for your highest end phones, not Mediatek.

PS. I don't think it's correct to say "a lot of things" are more important than the SoC. The SoC is probably the most important thing along with the screen. So maybe one thing is more important than the SoC - not "a lot".

Build quality, form factor, screen, waterproofing, wireless charging, charging speed, battery capacity, software customisations... There's a LOT of other things that go into a phone.

Samsung has sold flagship phones with slower Exynos processors internationally for years, and they've beaten LG, HTC, Sony etc.

The vast majority of people who buy phones don't even know what processor is in their phone, and don't understand or care about a Geekbench result.