Nuvia: don’t hold your breath

Yoused said:
Here is an image that seems to suggest three versions of the SoC
linked site
img.png

It looks from the chart as though Qualcomm may be going big.little in some of the second gen. The linked site is difficult to read, as the text is mostly Hangul.
Click to expand...
I think that chart has mashed the current generation with the next one. Those X Elite and Plus models are the current ones. I do believe that the next generation of Qualcomm chips will be big.Little, but while the current ones had an 8+4 config, they were all the same core.
 
SoftBank buying Ampere and ARM to actually make chips for Meta:

www.notebookcheck.net

Arm to enter the chip making business with Meta as a confirmed customer

Financial Times reports that Arm plans to launch its own line of chips in the coming months. They will supposedly power servers at Meta, who is said to be Arm's first major client.
www.notebookcheck.net www.notebookcheck.net

This came up during the trial when ARM waffled on whether they would do this saying they had explored it but abandoned the idea because they would be competing with their customers. I guess they changed their mind. I believe ARM is continuing to challenge the previous case, but only the question, about Nuvia's license, that the jury was hung on rather than both.
 
“
Snapdragon vs Lunar Lake Part 2

I posted on here about a week and a half ago asking if i should get the snapdragon or Lunar lake SL7. I ended up buying both with plans to return one. Here are the differences I noticed aside from software/hardware compatibility.

1. The snapdragon is much smoother than the lunar lake in terms of scrolling, pinch/zoom, opening/closing windows, and TouchPad gestures. The animations for snapdragon are buttery smooth in moving from window to window or desktop and the lunar lake seems to have a delay and/or drop in framerate. Sometimes the animations just don't work at all and it just "jumps" straight to the desktop. This is a huge deal breaker for me as I wanted a windows laptop with a similar feel as a macbook. Once I've used the snapdragon it is hard to go back to the Intel one.

2. Lunar lake fan noise kicks in more often (although it's still quiet)

3. Lunar lake gets medium warm-hot on the bottom, specifically in the middle towards the back closer the the hinges.
Click to expand...
 
Another commenter;

“
I ran some totally unscientific tests on an ARM SP11 by loading up explorer, the start menu and quick settings menu while monitoring resource usage in Task Manager. CPU and GPU usage shoot up quickly to 10% and then quickly ramp down to idle.

The Lunar Lake GPU has much higher performance compared to Adreno so it can't be the GPU contributing to snappiness. I think it's a combination of the Windows scheduler and the Oryon core design that allows extremely fast voltage/frequency ramp-up for performance and then ramping down to idle just as fast for efficiency. It really feels like an Apple Silicon MacBook.”
 
Yeah in truth lunar lake big core ST is as good as Oryon for Integer (which again says a lot about Intel given this crafty skunk works effort, so should horrify them) on performance/w and performance. And the e cores are a bit better at very low power.

This is something that’s missed even if the dynamic power is fine I think. They can’t us their p core cluster the same way QC would or Apple. It has lower latency and a great memory subsystem but like, is that worth it overall? Doubtful.


could be a firmware issue with scheduling per MS but I think most likely there may really be something to the idea Oryon can ramp faster and Intel is more cautious about using P cores in the real world, because even having those at near idle sucks extra power due to their awful fabric for the P cores.

Qualcomm’s clusters design are the closest to Apple by all structural means we can tell.
 
dada_dave said:
I think that chart has mashed the current generation with the next one. Those X Elite and Plus models are the current ones. I do believe that the next generation of Qualcomm chips will be big.Little, but while the current ones had an 8+4 config, they were all the same core.
Click to expand...
Yep
 
www.tomshardware.com

‘Frequently returned item' warning slapped on Snapdragon X-powered Surface Laptop 7 at Amazon

Software compatibility issues may be a factor in the higher return rate.
www.tomshardware.com www.tomshardware.com

Apparently high rates of return for Snapdragon powered Surface laptops often software compatibility issues. 10+ years of trying to get ARM-based windows machines to take off and MS haven’t been able to get this right. Qualcomm is also partially responsible, but mostly MS, especially for the software ecosystem.
 
mr_roboto said:
It feels bad to type these words, for much the same reason - but to be fair to QC, you guys had just a wee a bit of a baked-in advantage when it came to x86 Windows compatibility. ;)
Click to expand...
We had to work really hard to make sure the new stuff would be transparent to the user. My colleagues worked very closely with Microsoft for a long time, and we had people working on Linux support too.

Look at apple - twice they’ve done this sort of transition and both times it’s worked great.

You can’t give QC a pass here just because the PC ecosystem is divided up so everyone can point the finger at someone else. If you don’t control the OS then you better do everything you can to make sure the entity that does makes it work, or fill in that gap yourself. They could have provided their own “Rosetta,” e.g.
 
Cmaier said:
We had to work really hard to make sure the new stuff would be transparent to the user. My colleagues worked very closely with Microsoft for a long time, and we had people working on Linux support too.

Look at apple - twice they’ve done this sort of transition and both times it’s worked great.

You can’t give QC a pass here just because the PC ecosystem is divided up so everyone can point the finger at someone else. If you don’t control the OS then you better do everything you can to make sure the entity that does makes it work, or fill in that gap yourself. They could have provided their own “Rosetta,” e.g.
Click to expand...
Except in this case the transition was MS driven. Qualcomm may have been their main CPU partner for years, but the initial Surface devices from 2012-2015 had Nvidia Tegras. That doesn’t absolve Qualcomm for the all issues on their end, but MS was supposedly in charge and ultimately it’s their ecosystem to manage.
 
dada_dave said:
Except in this case the transition was MS driven. Qualcomm may have been their main CPU partner for years, but the initial Surface devices from 2012-2015 had Nvidia Tegras. That doesn’t absolve Qualcomm for the all issues on their end, but MS was supposedly in charge and ultimately it’s their ecosystem to manage.
Click to expand...
you don’t think MS was in charge when we did it? Remember, we had maybe 5% of the x86 market, if we were lucky, and almost all of that was third tier direct-to-consumer stuff. And MS had 99% of the x86 OS market. You had Intel doing Merced/Itanium and we weren’t going to be compatible with that. We weren’t exactly in a position to dictate terms to anyone. And we knew we had to be 100% compatible with everything out there so we weren’t exactly passive about our relationship with MS. It wasn’t “hey, it’s your OS, so we’ll leave it to you.” We worked directly with their kernel guys, and gave them what they needed to make it work. And by working with the linux kernel we discovered some stuff on our own. We helped MS make it work, and they helped us.

Which is a long way of saying, we very much thought MS was in charge when we did the thing we did - we were 100% at their mercy because if they didn’t support it, or if they supported it badly, we were cooked - and we did everything in our power to make sure that what MS did would work for MS’s customers.
 
Huge difference is the approach Apple and MSFT take in terms of legacy support too. Apple since the advent of OS X has walked the line between carrot and stick with OS updates to minimize the cost of legacy support. Carbon and its deprecation in 64-bit for example. Phasing out the previous architecture and outlining a timeframe for the hardware switch. And they tend to be more willing to do piecemeal stuff in between the larger changes that lay the foundation for them, or new hardware a year or two down the road. On one hand it makes supporting the platform a bit more costly as a developer because they are shifting things every couple years to some extent, but the flip side is that cost is amortized over a longer period of time and ultimately the teams I’ve worked on had clear ideas on how to get from A to B during Apple’s shifts.

But if you haven’t had to clean up your 32-bit unclean code unless there is a specific business need? If you haven’t had to consider anything past 90s era Win32 APIs? Welp, have fun. All the things that we cleaned up on the Mac side years ago because we had to, and now don’t worry about are still in your face on Windows. Plugin architectures on legacy apps are a fun one (I remember working on that with the 64-bit transition on Mac Office) for example. Windows is having to try to translate both 32-bit and 64-bit x86 and apparently compatibility isn’t equal across the two(?). In other words, MSFT and their developers are eating a much bigger meal in this transition all at once.

That and MSFT and their developers are taking a wait-and-see approach with ARM, where they wait for critical mass before going all in. Good luck with that.
 
Cmaier said:
you don’t think MS was in charge when we did it? Remember, we had maybe 5% of the x86 market, if we were lucky, and almost all of that was third tier direct-to-consumer stuff. And MS had 99% of the x86 OS market. You had Intel doing Merced/Itanium and we weren’t going to be compatible with that. We weren’t exactly in a position to dictate terms to anyone. And we knew we had to be 100% compatible with everything out there so we weren’t exactly passive about our relationship with MS. It wasn’t “hey, it’s your OS, so we’ll leave it to you.” We worked directly with their kernel guys, and gave them what they needed to make it work. And by working with the linux kernel we discovered some stuff on our own. We helped MS make it work, and they helped us.

Which is a long way of saying, we very much thought MS was in charge when we did the thing we did - we were 100% at their mercy because if they didn’t support it, or if they supported it badly, we were cooked - and we did everything in our power to make sure that what MS did would work for MS’s customers.
Click to expand...
I understand but what I’m trying to say is that this was a MS initiated project. They weren’t just in charge because of their command of the ecosystem. Qualcomm wasn’t even the initial processor vendor. MS chose Nvidia originally. MS then chose Qualcomm. Again Qualcomm has been their partner for a decade so yes they absolutely deserve some of the blame as well but MS has blundered from bad decision to bad execution and back - heck even on the x86 side I’ve seen people becoming increasingly frustrated with MS’ decisions and poor execution. Their ARM implementation just gets it worse because it has to deal with that and all the compatibility issues, especially legacy compatibility. And even if we were to lay a greater portion of the blame at Qualcomm’s feet, MS chose to stick with them and not even try to find new ways to motivate them.

When told the workers are working as fast as they can Vader ...

MS was always saying how much of a priority the success of WoA is, but never acted in concerted, organized fashion to actually make it happen.

Nycturne said:
Huge difference is the approach Apple and MSFT take in terms of legacy support too. Apple since the advent of OS X has walked the line between carrot and stick with OS updates to minimize the cost of legacy support. Carbon and its deprecation in 64-bit for example. Phasing out the previous architecture and outlining a timeframe for the hardware switch. And they tend to be more willing to do piecemeal stuff in between the larger changes that lay the foundation for them, or new hardware a year or two down the road. On one hand it makes supporting the platform a bit more costly as a developer because they are shifting things every couple years to some extent, but the flip side is that cost is amortized over a longer period of time and ultimately the teams I’ve worked on had clear ideas on how to get from A to B during Apple’s shifts.

But if you haven’t had to clean up your 32-bit unclean code unless there is a specific business need? If you haven’t had to consider anything past 90s era Win32 APIs? Welp, have fun. All the things that we cleaned up on the Mac side years ago because we had to, and now don’t worry about are still in your face on Windows. Plugin architectures on legacy apps are a fun one (I remember working on that with the 64-bit transition on Mac Office) for example. Windows is having to try to translate both 32-bit and 64-bit x86 and apparently compatibility isn’t equal across the two(?). In other words, MSFT and their developers are eating a much bigger meal in this transition all at once.

That and MSFT and their developers are taking a wait-and-see approach with ARM, where they wait for critical mass before going all in. Good luck with that.
Click to expand...

Yes this wait and see approach has, to me, been the key difference and a lot of that is on MS. That said, I’ve seen developers compare Qualcomm unfavorably to even Apple in terms of offering meaningful support to transition their products. When developers say they got better support from Apple than Qualcomm/MS, given how much they typically complain about Apple, that’s not a good thing. So again I don’t dispute that Qualcomm has been a mess here too. Qualcomm has for years bragged that WoA really meant Windows on Qualcomm without much success in the market to back up their crowing.
 
Last edited:
Back
Top