Here's my big question: are there datasheets/programmers manuals available or is this yet another proprietary mess of a SoC that ships undocumented Linux drivers with binary blobs? No thanks.
I will not spend money on hardware no one can reliably patch or write drivers for. I also want other operating system maintainers to be able to write drivers and get booting.
With them only merging upstream now, it'll be a while before you can actually use Linux on these devices. You can build your own kernel from upstream, but it's probably a better idea to wait until Arch or Gentoo package the necessary pre-configured kernels.
From what I can tell, the Elite SoCs are a lot less outdated-semi-proprietary-Linux-fork-y than many other Qualcomm chips.
That means nothing for the community who may need or want to fix and patch issues on their own. Instead we're beholden to Qualcomm to fix major issues on an OS it may or may not care about supporting. It also excludes other open source operating systems such as the BSD's who have to then reverse engineer the undocumented Linux drivers.
A better question: can a small company like Framework or even MNT Research build and support an open laptop around this chip?
While not this chip, MNT Research has been working on a processor module for Qualcomm Dragonwing QCS6490 and is manufacturing the first wave of test PCBs now:
Framework doesn't even develop their own firmware; most of the engineering in PCs is done by Intel/AMD/ODMs/IBVs. The whole ecosystem is based on vendor support not datasheets.
Firmware is not preventing Framework or anyone from offering a repairable laptop. Firmware also doesn't matter once the kernel is loaded. We need the datasheets.
This article seems to be about Qualcomm adding the device trees for the X2 CPUs. Which isn't the first gen.
As someone with a first gen, the device trees are, as I understand it, one of the issues with trying to just install any distro, except for that special Ubuntu one.
I can't just (for example) grab the latest fedora, and try and run that.
As someone who has used the Snapdragon X Elite (12 core Oryon) Dev Kit as a daily driver for the past year, I find this exciting. The X Elite performance still blows my mind today - so the new X2 Elite with 18 cores is likely going to be even more impressive from a performance perspective!
I can't speak to the battery life, however, since it is dismal on my Dev Kit ;-)
Surface Pro 11 owner here. SQL Server won't install on ARM without hacks. Hyper-V does not support nested virtualization on ARM. Most games are broken with unplayable graphical glitches with Qualcomm video drivers, but fortunately not all. Most Windows recovery tools do not support ARM: no Media Creation Tool, no Installation Assistant, and recovery drives created on x64 machines aren't compatible [EDIT: see reply, I might be mistaken on this]. Creation of a recovery drive for a Snapdragon-based Surface (which you have to do from a working Snapdragon-based Surface) requires typing your serial code into a Microsoft website, then downloading a .zip of drivers that you manually overwrite onto the recovery media that Windows 11 creates for you.
Day-to-day, it's all fine, but I may be returning to x64 next time around. I'm not sure that I'm receiving an offsetting benefit for these downsides. Battery life isn't something that matters for me.
You ABSOLUTELY do not have to create a recovery drive from a Snapdragon based device. I've done it multiple times from x64 Windows for both a SPX and 11.
Hmm, thank you, that's good to know. Did you just apply the Snapdragon driver zip over the x64 recovery drive? It didn't work for me when my OS killed itself but I could easily have done something wrong in my panic over the machine not working. Since I only have the one Snapdragon device, I was making the assumption that it would have worked if I had a second one, but I didn't actually know that.
One reason is that Apple sold subsidized devkits to developers starting around 6 months before Apple Silicon launched, while the X Elite devkit was not subsidized, came with Windows 11 Home (meaning that you had to pay another $100 to upgrade to Pro if you were an actual professional developer who needed to join the computer to your work domain), and didn't ship until after months after X Elite laptops started shipping. As a result, when the X Elite launched basically everything had to run under emulation.
I think another reason is Apple's control over the platform vs Microsoft's. Apple has the ability to say "we're not going to make any more x86 computers, you're gonna have to port your software to ARM", while Microsoft doesn't have that ability. This means that Snapdragon has to compete against Intel/AMD on its own merits. A couple months after X Elite launched, Intel started shipping laptops with the Lunar Lake architecture. This low-power x86 architecture managed to beat X Elite on battery life and thermals without having to deal with x86 emulation or poor driver support. Of course it didn't solve Intel's problems (especially since it's fabricated at TSMC rather than by Intel), but it demonstrated that you could get comparable battery life without having to switch architectures, which took a lot of wind out of X Elite's sails.
Apple had a great translation layer (Rosetta) that allows you to run x64 code, and it's very fast. However, Apple being Apple, they are going to discontinue this feature in 2026, that's when we'll see some Apple users really struggling to go fully arm, or just ditch their MacBook. I know if Apple does follow through with killing Rosetta, I'll do the latter.
Did it? From that list: SQL server doesn't work on Mac and there's no Apple equivalent, virtualisation is built into the system so that kind of worked but with restrictions, games barely exist Mac so a few that cared did the ports but it's still minimal. There's basically no installation media for Macs in the same way as windows in general.
What I'm trying to say is - the scope is very different / smaller there. There's a tonne of things that didn't work on Macs both before and after and the migration was not that perfect either.
Apple already went through this before with PowerPC -> x86. They had universal binaries, Rosetta, etc. to build off of. And they got to do it with their own hardware, which includes some special instructions intended to help with emulation.
> Apple already went through this before with PowerPC -> x86
Not to mention 68K -> PowerPC.
Rhapsody supported x86, and I think during the PowerPC era Apple kept creating x86 builds of OS X just in case. This may have helped to keep things like byte order dependencies from creeping in.
Every Mac transitions to ARM, only a very small amount of Windows PCs are running ARM. SO right now there's not an large user base to incentivise software to be written for it.
You are right that Windows on ARM cannot be called a success. But if you make Windows/macOS cross platform software then your software needs to be written for ARM anyway.
So if you support macOS/x86, macos/ARM, and Windows/x86, then the additional work to add Windows/ARM is rather small, unless you do low-level stuff (I remember Fortnite WoA port taking almost a year from announcement to release due to anticheat).
>Creation of a recovery drive for a Snapdragon-based Surface (which you have to do from a working Snapdragon-based Surface) requires typing your serial code into a Microsoft website, then downloading a .zip of drivers that you manually overwrite onto the recovery media that Windows 11 creates for you.
That's just creation of a recovery drive for anything that Microsoft itself makes. It's the same process for the Intel Surface devices too.
>no Media Creation Tool
Why would anyone care about that? Most actively avoid Microsoft's media creation tool and use Rufus instead.
I have a similar Windows Arm64 machine (Lenovo "IdeaPad 5 Slim"), RDP into it works OK.
There is one issue I ran into that I haven't on my (self-built) Windows desktops: when Windows Hello (fingerprint lock) is enabled, and neither machine is on a Windows domain, the RDP client will just refuse to authenticate.
On the bright side, there's a good chance that Windows on ARM is not well supported by malware. There's a situation where you benefit from things being broken.
Yeah, I too was surprised to find the dev experience very good: all JetBrains IDEs work well, Visual Studio appears to work fine, and most language toolchains seem well supported.
Have I had any app compatibility issues?
To quote Hamlet, Act 3, Scene 3, Line 87: "No."
The Prism binary emulation for x86 apps that don't have an ARM equivalent has been stellar with near-native performance (better than Rosetta in macOS). And I've tried some really obscure stuff!
I suspect that's due to the GPU and not due to Prism, because they basically just took a mobile GPU and stuffed it into a laptop chip. Generally performance seems to be on par with whatever a typical flagship Android devices can do.
Desktop games that have mobile ports generally seem to run well, emulation is pretty solid too (e.g. Dolphin). Warcraft III runs OK-ish.
Ironically, the app I've had the most trouble with is Visual Studio 2022. Since it has a native ARM64 build and installation of the x64 version is blocked, there are a bunch of IDE extensions that are unavailable.
Today Qualcomm CEO stated[0] that the combination of Android and ChromeOS, e.g. Android Computers, will be available on Snapdragon laptops. Maybe these X2 CPUs will be in those laptops.
For people complaining about battery control and android emulation on linux, ChromeOS is a boon.
You effectively get an actual Linux distro + most of android, with a side of Chrome. It's way closer to "a real computer" than an iPad for instance, and only loses to the Surface Pro/Z13 line in term of versatility IMHO.
It really wasn't bad, my only deal breakers were keyboard remapping being non existent and the bluetooth stack being flaky.
I got a ChromeOS device a few years ago and it was great. I think they get an underserved bad reputation from being the locked-down devices you're forced to use in schools, but a personal ChromeOS device is a capable computer that can run any Android app or desktop Linux app.
Though having said that, in the past year I've replaced ChromeOS with desktop Linux (postmarketOS) and I love it even more now. 4GB of RAM was a bit slim for running everything in micro-VMs for "security," which is what ChromeOS does. I've had no trouble with battery life or Android emulation (Waydroid) since switching.
If you look at the verified hardware list for ChromeOS Flex[0], you can get an idea of what ChromeOS devices are being deployed for. Apart from education and companies that use Google Workspace, there's a lot of ChromeOS devices deployed as kiosks and call center computers. This is reflected not only in obscure documentation, but also in the marketing material[1].
The "enterprise" managability and reduced attack surface is driving Google to jack up Chromebook prices. The "Chromebook Plus" models are nearing the same price as a midrange Dell Inspiron, HP OmniBook, or Lenovo IdeaPad. You may have also noticed M4 MacBook Airs can be bought for the price of an iPhone 17, and I suspect that's partially a response from Apple to the Chromebook price increases. Buying a $600 Chromebook might have been sane for someone tired of Microsoft and not interested in a $1000 Macbook Air, but in 2025, with the Macbook Air prices going down significantly[2], Chromebooks are not as appealing to regular consumers (different story for businesses).
We’ve been using X Elite Snapdragon laptops (Thinkpad T14s and Yoga Slim running Ubuntu’s concept images) to build large amounts of ARM software without the need for cross-compiling. The hardware peripheral support isn’t 100% yet (good enough) but I’ve been impressed with the performance.
ARM seems to be popular in the server space and it’s nice to see it trickling down to the PC market.
To be fair, they did say "PC" specifically. It's not uncommon to consider that a category that doesn't include Apple (e.g. the "I'm a Mac" "I'm a PC" ads from years ago)
People just need to quit using the term "PC" to refer to desktop or laptop hardware that happens to be running Windows. Laptops running MacOS are "personal computers," as are desktops running Linux, or effing phones running Android, for that matter.
I think the issue is that there's clearly as need for a term for the category of "things that usually run Windows (but you can also probably put Linux on it, and like, even one of the BSDs if you're feeling adventurous)". PC isn't a great one from a linguistic perspective, but there's not an alternative I've heard that seems likely to catch on. There probably also should be a better term for "laptop/desktop", since as you mention "computer" itself is not really narrow enough if you're being pedantic, but at the end of the day, right now the only really differentiator we have is context. In the context here, it was honestly more clear clear what was meant by "PC" in the top-level comment than it was whether the person responding to it actually misunderstood or was trying to make a point.
Did qualcomm ever get its act together with firmware/drivers and linux? It's a dead end to me if they aren't at an Intel/AMD level of openness on this front.
Their top model still only has "Up to 228 GB/s" bandwdith which places it in the low end category for anything AI related, for comparison Apple Silicon is up to 800GB/s and Nvidia cards around 1800GB/s and no word if it supports 256-512GB of memory.
> Their top model still only has "Up to 228 GB/s" bandwdith which places it in the low end category for anything AI related, for comparison Apple Silicon is up to 800GB/s
Most Apple Silicon is much less than 800 GB/s.
The base M4 is only 120GB/s and the next step up M4 Pro is 273GB/s. That’s in the same range as this part.
It’s not until you step up to the high end M4 Max parts that Apple’s memory bandwidth starts to diverge.
For the target market with long battery life as a high priority target, this memory bandwidth is reasonable. Buying one of these as a local LLM machine isn’t a good idea.
This, and always check benchmarks instead of assuming memory bandwidth is the only possible bottleneck. Apple Silicon definitely does not fully use its advertised memory bandwidth when running LLMs.
The base model X2 Elite has memory bandwidth of 152 GB/s. M4 Pro is a modest win against the Extreme as mentioned, and Qualcomm has no M4 Max competitor that I'm aware of.
I think the pure hardware specs compare reasonably against AS, aside from the lack of a Max of course. Apple's vertical integration and power efficiency make their product much more compelling though, at least to me. (Qualcomm, call me when the Linux support is good.)
Yet the apps top the App Store charts. Considering that these are not upgradable I think the specs are relevant. Just as I thought Apple shipping systems with 8 GB minimums was not good future proofing.
These all have nightmarish support. They're not a big deal for Qualcomm so the driver support is garbage. And you're stuck on their kernel like one of those Raspberry Pi knock offs. It's just really hard to take them seriously.
> And you're stuck on their kernel like one of those Raspberry Pi knock offs. It's just really hard to take them seriously.
Qualcomm has beem mainlining Snapdragon X drivers to the 6.x kernel tree for over a year now. There have been multiple frontpage HN posts about this in the past 12 months.
Webcam/mic/speaker support may be a WIP depending on your model, but snapdragon X Elite has been booting Linux for months now, using only drivers in Linus' tree. The budget chips (Snapdragon X Plus) have far less direct support form Qualcomm, but some independent hackers have put in heroic effort to make those run Linux too.
Does anybody know if the X2 supports the x86 Total store ordering (TSO) memory ordering model? That's how Apple silicon does such efficient emulation of x86. I'd think that would be even MORE important for a Windows ARM64 laptop where there is so much more legacy x86 software going back decades.
Does anyone have benchmarks for Rosetta with TSO vs the Linux version with no-TSO? I guess it might be a bit challenging to achieve apples to apples, although you could run a test benchmark on OSX and then Asahi on the same hardware, I think?
I've always been curious about just how much Rosetta magic is the implementation and how much is TSO; Prism in Windows 24H2 is also no slouch. If the recompiler is decent at tracing data dependencies it might not have to fence that much on a lot of workloads even without hardware TSO.
People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed, other factors like enhanced hardware flag conversion support and function call optimizations play a significant role too:
> People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed
This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulated code (such as the emulator itself or in ARM64EC).
The claimed conclusion is that it's better to optimize TSO emulation itself rather than bruteforce it on the hardware level. The way Microsoft achieved this is by having their compiler generate metadata about code that requires TSO and by using ARM64EC, which forwards any API calls to x86 system libraries to native ARM64 builds of the same libraries. Note how the latter in particular will shift the balance in favor of software-based TSO emulation since a hardware-based feature would slow down the native system libraries.
Without ecosystem control, this isn't feasible to implement in other x86 emulators. We have a library forwarding feature in FEX, but adding libraries is much more involved (and hence currently limited to OpenGL and Vulkan). We're also working on detecting code that needs TSO using heuristics, but even that will only ever get us so far. FEX is mainly used for gaming though, where we have a ton of x86 code that may require TSO (e.g. mono/Unity) but wouldn't be handled by ARM64EC, so the balance may be in favor of hardware TSO either way here.
For reference, this is the paragraph (I think) you were referring to:
> Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.
How is it a misinterpretation? To re-quote that last sentence:
> In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper.
That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and other non-emulated code in the same process that are fine running non-TSO, but to users, this distinction doesn't matter. All that matters is the performance of emulated program as a whole.
As for the volatile metadata, you're correct that MSVC inserts additional data to aid the emulation. What's not so great is that:
- It was basically an almost undocumented, silent addition to MSVC.
- In some cases, it will slow down the generated x64 code slightly by adding NOPs where necessary to disambiguate the volatile access metadata.
- It only affects code statically compiled with a recent version of MSVC (late VS2019 or later). It doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.
For really old software, it tends not to make good use of multiple cores anyway and you can simply emulate just a single core to achieve total store ordering.
Anything modern and popular and you can probably get it recompiled to ARM64
Unfortunately games are the most common demanding multithread applications. Studios throw a binary over the fence and then get dissolved. Seems to be the way the entire industry operates.
Maybe more ISA diversity will incentivize publishers to improve long-term software support but I have little hope.
If Snapdragon (or ARM players in general) wanted to challenge x86 and Apple dominance, do they need to compete in the exact same arena? Could they carve out a niche (example: ultra-efficient always-on machines) and then expand?
Exactly! That makes this move all the more interesting. The smartphone SoC market is saturated, and margins are shrinking. Laptops/PCs give Qualcomm a chance to leverage its IP in a higher-ASP segment. Expanding is logical, but the competitive bar is way higher.
“ARM chip” is a pretty broad umbrella. Apple’s M-series is based on the ARM ISA, the microarchitecture is Apple’s own design, and the SoCs are built with very different cache hierarchies, memory bandwidth, and custom accelerators. I was simply using Apple as an example of another big player.
“Multi-day” battery life sounds wild! That’s probably the biggest thing for users. It would be good for Apple to get some competition because their M-chips seemed so far away from everything else.
Still, even if someone uses it for two hours a day and then just closes it being able to run for multiple days without charging the way Macs can is fantastic.
I agree it seems incredibly unlikely that you’re doing multiple days of eight hours of work without charging.
Longer is always better, so if it’s true at all great for them.
Any battery life claim needs to be aligned with the consumer-class operating system and application layer (iOS, Android, etc). Multi-day battery life on a non-Google-Pixel Android device with typical usage would be interesting.
I you're willing to go back a few generations, Asahi Linux supports the Mac Mini (M1, M2 and M2 Pro). Support is missing for USB-C displays (it has HDMI) and Thunderbolt, but other than that you can have an awesome experience on these (and probably get yourself a good deal these days)
FOSS support for Windows ARM has been hampered by Github (owned by MS) not supporting free Windows ARM runners. They may be finally getting their act together but are years late to the game.
AFAIK Windows on ARM is completely pushed by Microsoft (obviously they're limited by their own competence) and Qualcomm has been kind of phoning it in.
I trust MS in this. NT has been multi-arch since day one. x86 wasn’t even the original lead architecture.
They also know the score. Intel is not in a good place, and Apple has been showing them up in lower power segments like laptops, which happen to be the #1 non-server segment by far.
They don’t want to risk getting stuck the way Apple did three times (68k, POC, Intel) where someone else was limiting their sales.
So they’re laying groundwork. If it’s a backup plan, they’re ready. If ARM takes off and x86 keeps going well, they’re even better off.
When laptop OEMs stop catering to the lowest common denominator corporate IT purchasers (departments which don't care about screen quality, speaker quality, or much of anything else outside of does the spec sheet on paper match our requirements and is it cheap).
I have a Yoga Slim 7x, which has the ARM. Screen quality is fantastic along with build quality, touchpad and keyboard feel :shrug:
It really depends on what Laptop line you buy. Dells have overwhelmingly become garbage, right next to HP.
Speaker quality on a laptop oth? Couldn't care less, I use headphones/earbuds 99% of the time because If I'm going portable computer, I'm traveling and I don't want to be an inconsiderate arse.
The Yoga Slim 7x is a rather unique outlier. I was on the market for a non-Mac laptop a little while ago, and the was literally the only one that met my standards.
> departments which don't care about screen quality, speaker quality, or much of anything else outside of does the spec sheet on paper match our requirements and is it cheap)
Translation: departments which don't care about worker's wellbeing.
Looking at the SOCs used, only Dell, Microsoft, and Samsung used the 2nd fastest SoC, the X1E-80-100 - the Dell and Microsoft laptops could be configured with 64GB soldered.
Samsung also used the fastest SoC (the only OEM to do so), the X1E-84-100. From a search of their USA website, you're stuck with only 16GB on any of their Snapdragon laptops. :(
I'd hope whichever OEM(s) uses the Snapdragon X2 Elite Extreme SoC (X2E-96-100) allows users to configure RAM up to 64GB or 128GB.
I’m a huge Framework fan: preordered the 13 and Desktop, have done mainboard + LCD upgrades on personal and work machines, etc. Likewise, I’ve used ARM machines as general-purpose Linux workstations, starting with the PineBook Pro up to my current Radxa Orion. It seems like a great combo!
Unfortunately, firmware and OS support are hard for any vendor, especially one as small (compared to, say, Lenovo or HP) and fast-moving as Framework. Spreading that to yet another ISA and driver ecosystem seems like it would drag down quality and pace of updates on every other system, which IMHO would be a bad trade.
I'm holding my breath though. I have a Samsung Edge 4 laptop and I didn't find the battery life impressive - prob got around 6 hours under coding / programming tasks. GPU performance is terrible too.
I feel like I'm constantly charger-tending all my non-Apple silicon laptops.
M-series instant wake from sleep is also years ahead of the Windows wakeup roulette, so even if this new processor helps with time away from chargers... we still have the Windows sleep/hibernate experience.
You can probably pretty easily just say Prime==Performance and Performance==Efficiency, but I think the "Prime" branding is kind of a carry over from Snapdragon mobile chips where they commonly use three tiers of core designs rather than the two. They still want to advertise the tier 2 cores as fast so T3 is efficiency, T2 is performance, T1 is Prime.
As an example, the Snapdragon 700-series had Prime, Gold, and Silver branding on it's cores.
the snapdragon x2 elite extreme (X2E-96-100) SoC supports "128GB+" but qualcomm hasn't specified what the max limit is. this soc also has higher memory bandwidth (228GB/s over 192-bit bus) than the x2 elite.
Linux support is still basically non-existent for the first gen, and they made all this deal about supporting Linux and the open source community. This is to say, don't trust them
That'd definitely fit the Qualcom pattern of trying to force you to update by not upstreaming their linux drivers.
This is one place where windows has an advantage over linux. Window's longterm support for device drivers is generally really good. A driver written for Vista is likely to run on 11.
Old situation: "Android drivers" are technically Linux drivers in that they are drivers which are built for a specific, usually ancient, version of Linux with no effort to upstream, minimal effort to rebase against newer kernels, and such poor quality that there's a reason they're not upstreamed.
New situation: "Android drivers" are largely moved to userspace, which does have the benefit of allowing Google to give them a stable ABI so they might work against newer kernels with little to no porting effort. But now they're not really Linux drivers.
In neither case does it really help as much as you'd hope.
Not surprising considering I haven't seen a programming manual or actual datasheet for these things in the first place. Usually helps if you tell the community how to interact with your hardware ..
Not even true: Arm, Intel, AMD, and most other hardware vendors (who are actively making an effort to support Linux on their parts) actually publish useful[^1] documentation.
edit: Also, not knocking the Qualcomm folks working on Linux here, just observing that the lack of hardware documentation doesn't exactly help reeling in contributors.
[^1]: Maybe in some cases not as useful as it could be when bringing up some OS on hardware, but certainly better than nothing
I wonder how much intended audience for these chips cares about “elite” and “ultra-premium” buzz wording. I’m sure it’s a good chip but cmon, it’s not for TikTok watching..
I will not spend money on hardware no one can reliably patch or write drivers for. I also want other operating system maintainers to be able to write drivers and get booting.
With them only merging upstream now, it'll be a while before you can actually use Linux on these devices. You can build your own kernel from upstream, but it's probably a better idea to wait until Arch or Gentoo package the necessary pre-configured kernels.
From what I can tell, the Elite SoCs are a lot less outdated-semi-proprietary-Linux-fork-y than many other Qualcomm chips.
A better question: can a small company like Framework or even MNT Research build and support an open laptop around this chip?
https://source.mnt.re/reform/reform-qcs6490
As someone with a first gen, the device trees are, as I understand it, one of the issues with trying to just install any distro, except for that special Ubuntu one.
I can't just (for example) grab the latest fedora, and try and run that.
Now, I haven't tried the latest beta of Fedora 43, but my guess is this won't change.
The reality is this company is notoriously a law firm with a small technical staff on the side.
I can't speak to the battery life, however, since it is dismal on my Dev Kit ;-)
https://www.pcworld.com/article/2375677/surface-laptop-2024-...
X2 Elite shouldn't be that different I think.
ive a x elite and a bunch of other laptops
i like the mba 13 (but barely) and the zbook 395+
the x elite is just a bit slow,.incompatible and newer x86 battery life isnt far off
Edit: apparently they did end up shipping.
Day-to-day, it's all fine, but I may be returning to x64 next time around. I'm not sure that I'm receiving an offsetting benefit for these downsides. Battery life isn't something that matters for me.
I think another reason is Apple's control over the platform vs Microsoft's. Apple has the ability to say "we're not going to make any more x86 computers, you're gonna have to port your software to ARM", while Microsoft doesn't have that ability. This means that Snapdragon has to compete against Intel/AMD on its own merits. A couple months after X Elite launched, Intel started shipping laptops with the Lunar Lake architecture. This low-power x86 architecture managed to beat X Elite on battery life and thermals without having to deal with x86 emulation or poor driver support. Of course it didn't solve Intel's problems (especially since it's fabricated at TSMC rather than by Intel), but it demonstrated that you could get comparable battery life without having to switch architectures, which took a lot of wind out of X Elite's sails.
What I'm trying to say is - the scope is very different / smaller there. There's a tonne of things that didn't work on Macs both before and after and the migration was not that perfect either.
Not to mention 68K -> PowerPC.
Rhapsody supported x86, and I think during the PowerPC era Apple kept creating x86 builds of OS X just in case. This may have helped to keep things like byte order dependencies from creeping in.
So if you support macOS/x86, macos/ARM, and Windows/x86, then the additional work to add Windows/ARM is rather small, unless you do low-level stuff (I remember Fortnite WoA port taking almost a year from announcement to release due to anticheat).
That's just creation of a recovery drive for anything that Microsoft itself makes. It's the same process for the Intel Surface devices too.
>no Media Creation Tool
Why would anyone care about that? Most actively avoid Microsoft's media creation tool and use Rufus instead.
When I'm home, I often just remote desktop into my laptop.
I'm wondering if remoting into ARM Windows is as good?
There is one issue I ran into that I haven't on my (self-built) Windows desktops: when Windows Hello (fingerprint lock) is enabled, and neither machine is on a Windows domain, the RDP client will just refuse to authenticate.
I had to use a trick to "cache" the password on the "server" end first, see https://superuser.com/questions/1715525/how-to-login-windows...
Only major exception is: - Android Studio's Emulator (although, the IDE does work)
Plus they’ve been through the Apple Silicon change, so it’s not the first time they’ve been on non-x86 either.
The Prism binary emulation for x86 apps that don't have an ARM equivalent has been stellar with near-native performance (better than Rosetta in macOS). And I've tried some really obscure stuff!
Desktop games that have mobile ports generally seem to run well, emulation is pretty solid too (e.g. Dolphin). Warcraft III runs OK-ish.
Adobe apps that ran fine on Rosetta didn't work at all on Prism.
https://www.pcmag.com/articles/how-well-does-windows-on-arms...
[0] https://www.techradar.com/phones/android/ive-seen-it-its-inc...
You effectively get an actual Linux distro + most of android, with a side of Chrome. It's way closer to "a real computer" than an iPad for instance, and only loses to the Surface Pro/Z13 line in term of versatility IMHO.
It really wasn't bad, my only deal breakers were keyboard remapping being non existent and the bluetooth stack being flaky.
Though having said that, in the past year I've replaced ChromeOS with desktop Linux (postmarketOS) and I love it even more now. 4GB of RAM was a bit slim for running everything in micro-VMs for "security," which is what ChromeOS does. I've had no trouble with battery life or Android emulation (Waydroid) since switching.
Cool if one wants to CLI stuff alongside Web and Android apps, but that is as far as it goes for GNU/Linux, with many yes but.
https://chromium.googlesource.com/chromiumos/docs/+/1792b43f...
The "enterprise" managability and reduced attack surface is driving Google to jack up Chromebook prices. The "Chromebook Plus" models are nearing the same price as a midrange Dell Inspiron, HP OmniBook, or Lenovo IdeaPad. You may have also noticed M4 MacBook Airs can be bought for the price of an iPhone 17, and I suspect that's partially a response from Apple to the Chromebook price increases. Buying a $600 Chromebook might have been sane for someone tired of Microsoft and not interested in a $1000 Macbook Air, but in 2025, with the Macbook Air prices going down significantly[2], Chromebooks are not as appealing to regular consumers (different story for businesses).
[0] https://support.google.com/chromeosflex/answer/11513094?sjid...
[1] https://chromeos.google/business-solutions/use-case/contact-...
[2] https://www.zdnet.com/article/the-m4-macbook-air-is-selling-...
ARM seems to be popular in the server space and it’s nice to see it trickling down to the PC market.
Most Apple Silicon is much less than 800 GB/s.
The base M4 is only 120GB/s and the next step up M4 Pro is 273GB/s. That’s in the same range as this part.
It’s not until you step up to the high end M4 Max parts that Apple’s memory bandwidth starts to diverge.
For the target market with long battery life as a high priority target, this memory bandwidth is reasonable. Buying one of these as a local LLM machine isn’t a good idea.
Given their top model underperforms the most common M4 chip and the M5 is about to be released it's not very impressive at all.
Even the old M2 Max in my early 2023 MacBook Pro has 400GB/s.
https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...
I think the pure hardware specs compare reasonably against AS, aside from the lack of a Max of course. Apple's vertical integration and power efficiency make their product much more compelling though, at least to me. (Qualcomm, call me when the Linux support is good.)
Ironically M1 chip is better supported on Linux.
Qualcomm has beem mainlining Snapdragon X drivers to the 6.x kernel tree for over a year now. There have been multiple frontpage HN posts about this in the past 12 months.
Webcam/mic/speaker support may be a WIP depending on your model, but snapdragon X Elite has been booting Linux for months now, using only drivers in Linus' tree. The budget chips (Snapdragon X Plus) have far less direct support form Qualcomm, but some independent hackers have put in heroic effort to make those run Linux too.
I've always been curious about just how much Rosetta magic is the implementation and how much is TSO; Prism in Windows 24H2 is also no slouch. If the recompiler is decent at tracing data dependencies it might not have to fence that much on a lot of workloads even without hardware TSO.
http://www.emulators.com/docs/abc_exit_xta.htm
This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulated code (such as the emulator itself or in ARM64EC).
The claimed conclusion is that it's better to optimize TSO emulation itself rather than bruteforce it on the hardware level. The way Microsoft achieved this is by having their compiler generate metadata about code that requires TSO and by using ARM64EC, which forwards any API calls to x86 system libraries to native ARM64 builds of the same libraries. Note how the latter in particular will shift the balance in favor of software-based TSO emulation since a hardware-based feature would slow down the native system libraries.
Without ecosystem control, this isn't feasible to implement in other x86 emulators. We have a library forwarding feature in FEX, but adding libraries is much more involved (and hence currently limited to OpenGL and Vulkan). We're also working on detecting code that needs TSO using heuristics, but even that will only ever get us so far. FEX is mainly used for gaming though, where we have a ton of x86 code that may require TSO (e.g. mono/Unity) but wouldn't be handled by ARM64EC, so the balance may be in favor of hardware TSO either way here.
For reference, this is the paragraph (I think) you were referring to:
> Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.
> In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper.
That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and other non-emulated code in the same process that are fine running non-TSO, but to users, this distinction doesn't matter. All that matters is the performance of emulated program as a whole.
As for the volatile metadata, you're correct that MSVC inserts additional data to aid the emulation. What's not so great is that:
- It was basically an almost undocumented, silent addition to MSVC.
- In some cases, it will slow down the generated x64 code slightly by adding NOPs where necessary to disambiguate the volatile access metadata.
- It only affects code statically compiled with a recent version of MSVC (late VS2019 or later). It doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.
(the downstream asahi kernel supports TSO)
Anything modern and popular and you can probably get it recompiled to ARM64
Maybe more ISA diversity will incentivize publishers to improve long-term software support but I have little hope.
I agree it seems incredibly unlikely that you’re doing multiple days of eight hours of work without charging.
Longer is always better, so if it’s true at all great for them.
Has Microsoft actually pushed for the ARM changes? Because I don't believe Qualcomm can do it alone.
AFAIK Windows on ARM is completely pushed by Microsoft (obviously they're limited by their own competence) and Qualcomm has been kind of phoning it in.
They also know the score. Intel is not in a good place, and Apple has been showing them up in lower power segments like laptops, which happen to be the #1 non-server segment by far.
They don’t want to risk getting stuck the way Apple did three times (68k, POC, Intel) where someone else was limiting their sales.
So they’re laying groundwork. If it’s a backup plan, they’re ready. If ARM takes off and x86 keeps going well, they’re even better off.
https://lore.kernel.org/lkml/20250925-v3_glymur_introduction...
EL2 support is huge, means virtualization will work on non-Windows OSes (e.g: Linux KVM), unlike with previous gen.
When laptop OEMs stop catering to the lowest common denominator corporate IT purchasers (departments which don't care about screen quality, speaker quality, or much of anything else outside of does the spec sheet on paper match our requirements and is it cheap).
It really depends on what Laptop line you buy. Dells have overwhelmingly become garbage, right next to HP.
Speaker quality on a laptop oth? Couldn't care less, I use headphones/earbuds 99% of the time because If I'm going portable computer, I'm traveling and I don't want to be an inconsiderate arse.
Translation: departments which don't care about worker's wellbeing.
They’re marketing to OEMs.
MS put out surface & surface laptop with it, Lenovo did do the ThinkPad X1 with it, and Dell put it in the XPS line.
Acer, Asus, Dell, HP, Lenovo, Microsoft, Samsung
Looking at the SOCs used, only Dell, Microsoft, and Samsung used the 2nd fastest SoC, the X1E-80-100 - the Dell and Microsoft laptops could be configured with 64GB soldered.
Samsung also used the fastest SoC (the only OEM to do so), the X1E-84-100. From a search of their USA website, you're stuck with only 16GB on any of their Snapdragon laptops. :(
I'd hope whichever OEM(s) uses the Snapdragon X2 Elite Extreme SoC (X2E-96-100) allows users to configure RAM up to 64GB or 128GB.
X13s was confirmed to be sunset, another T14s is the most likely candidate among the ThinkPads.
Unfortunately, firmware and OS support are hard for any vendor, especially one as small (compared to, say, Lenovo or HP) and fast-moving as Framework. Spreading that to yet another ISA and driver ecosystem seems like it would drag down quality and pace of updates on every other system, which IMHO would be a bad trade.
M-series instant wake from sleep is also years ahead of the Windows wakeup roulette, so even if this new processor helps with time away from chargers... we still have the Windows sleep/hibernate experience.
Not sure what a prime core is.
For comparison the M4 Pro can go as high as 10 performance cores and 4 efficiency cores.
Mind you, Geekerwan managed to push the A19 Pro to 4019 in Geekbench 6 by using active cooling. https://youtu.be/Y9SwluJ9qPI
As an example, the Snapdragon 700-series had Prime, Gold, and Silver branding on it's cores.
also see https://wccftech.com/snapdragon-x2-elite-extreme-die-package...
Clearly it's a priority because the support for ChromeOS/android support is a big headline this year.
[1] https://discourse.ubuntu.com/t/ubuntu-24-10-concept-snapdrag...
Also worth noting that not all the bits needing support are inside of the Snapdragon, so specific vendor support from Dell, Lenovo etc is required.
This is one place where windows has an advantage over linux. Window's longterm support for device drivers is generally really good. A driver written for Vista is likely to run on 11.
Old situation: "Android drivers" are technically Linux drivers in that they are drivers which are built for a specific, usually ancient, version of Linux with no effort to upstream, minimal effort to rebase against newer kernels, and such poor quality that there's a reason they're not upstreamed.
New situation: "Android drivers" are largely moved to userspace, which does have the benefit of allowing Google to give them a stable ABI so they might work against newer kernels with little to no porting effort. But now they're not really Linux drivers.
In neither case does it really help as much as you'd hope.
edit: Also, not knocking the Qualcomm folks working on Linux here, just observing that the lack of hardware documentation doesn't exactly help reeling in contributors.
[^1]: Maybe in some cases not as useful as it could be when bringing up some OS on hardware, but certainly better than nothing
I'm not a huge fan of working in WSL, because I actively dislike the Windows GUI.