I'm curious how long until most users just don't care if their CPU has native x86 support.
As someone developing HPC applications, I generally don't care either, as long as the hardware has good fundamentals, and is well supported by the available compilers and profiling tools.
Honestly at this point the only reason that I'm aware of to prefer Intel for my workloads is the awesomeness of VTune.
How's the quality of the equivalent AMD or Arm tooling these days?
chainingsolid · 2h ago
Personally for me I only care about x86 for 2 reasons.
1) Steam library.
2) And the just works combo of ATX & the ability to use any ISO on almost any x86 machine.
I'm personally scared if x86 dies the open market of ATX and bring your own OS won't exist as every company will just lock you in to only there stuff on their devices.
seanw444 · 2h ago
My hope is that the death of x86 results in everyone flocking to RISC-V.
jabl · 1h ago
RISC-V being an open source ISA does not imply that devices using that ISA won't be locked down.
An open ecosystem in the way that historically emerged around the PC platform seems to be a completely orthogonal issue.
Joker_vD · 2h ago
Which will drastically improve things with how the boot sequence(s) work and non-CPU devices are discovered, initialized, and managed, I am sure. So far, SBI doesn't look very promising.
monocasa · 2h ago
SBI doesn't attempt to handle that, just like EFI doesn't really handle that on x86. Just about every device your x86 computer uses looks like PCI (or on a bus hooked up to PCI), and is handled through those configuration mechanisms rather than via boot firmware.
FirmwareBurner · 40m ago
Who is this "everyone"? Just because RISCV ISA is open doesn't mean the ecosystem will be too. Because wile the ARM ISA is licensable by everyone so in theory everyone can be making X86 PCs, the current PC ARM ecosystem is way worse and way more locked down than X86.
Reminds me when people wanted Intel to die and then they realized AMD started raising their prices with no competition and they tough that maybe AMD isn't their friend and is like any other for profit corporation.
So I have no idea why people want to see the most open PC ecosystem die. What kind of short sighted masochism is this?
pacetherace · 43m ago
I think we are already past that point. With Apple Macbook, Google Chromebook and Microsoft Surface, we pretty much have all consumer computer echo system become ARM based.
Thanks to AMDs resurgence the server space is still heavily x86 based.
dagmx · 2h ago
The majority of compute users do not care.
Everyone who uses a tablet or smartphone obviously doesn’t care.
Anyone on a Mac doesn’t care, and even on windows, only very performance sensitive people would care if Prism isn’t doing its thing.
You’d essentially be left with AAA PC gamers and other performance sensitive people, which are a small percentage of overall users.
jtbayly · 2h ago
They don’t care until they can’t print... I had a user buy an ARM Windows device last year. I thought it was a sweet little computer, but the large multi-function Sharp printers don’t have drivers, so the best I could do was get basic printing working. Not double sided, not finishing options, etc. Pretty much a bummer that I expect to go away in the next few years, but still currently a place that can matter and cause people to lean x86.
zamadatix · 2h ago
Isn't there some big standardized/common print driver push going on in Windows 11 these days? I wonder if that's related.
I have an M1 MacBook Air I bought used a year ago for $800.
I edit a ton of 4K video, photos off my Sony Mirrorless, write articles, web, etc.
It is by far the fastest computer I’ve ever used. I have never once known or cared if anything is running x86.
saghm · 3h ago
The first time I got one of the ARM MacBooks from a job after years of being given the x86 ones, even my cats could immediately tell the difference. The x86 ones were basically constantly operating at a warm temperature that caused them to both want to nap on it, so they'd scuffle a few times a week when inevitably one of them tried to get on my desk only to find the other already napping there. In around 20 months of using M1 and newer laptops from employers, I've had a cat nap on them maybe three times total, because it pretty rarely is noticeably warmer than anything else in the room, so they have no special interest in it compared to much more enticing furniture like my keyboard.
dboreham · 1h ago
Working on the back-end side, there are still edge cases where ARM just doesn't work. You'll be using some container image and there's no ARM build. So you build it yourself and the build fails. After two days of poking and prodding it turns out the image is based on some wonky base image that has a libc that has never been ported to ARM. Re-creating the image on a different base turns out to be a big project. I've run into 2-3 similar but different issues like this in the past couple of years.
varispeed · 3h ago
Sadly some companies are stubborn and just won't support ARM. For instance if you need to use Autodesk Revit for work, you are sentenced to Windows x86 hell.
CoastalCoder · 1h ago
By what mechanism is Revit locked to x86?
E.g., does it refuse to run on an emulator? Or some bizarre license issue?
varispeed · 1h ago
It works on an emulator, but user experience is poor.
wtallis · 1h ago
Is that an x86 translation issue, or a graphics issue? The chips Qualcomm has shipped so far for ARM PCs have bad graphics hardware and worse drivers. And that's the best case, where the ARM system is at least running Windows and nominally supporting DirectX. If you try to run on a Linux system, you add in more layers of API translation that have nothing to do with the CPU instruction set.
ezcrypt · 4h ago
Tried box64 on a Raspberry Pi 5 the other day and it worked above expectations. Except for a minor glitch with OGG audio, I got about 60 FPS in Xonotic (x86_64 emulated on AArch64).
geerlingguy · 4h ago
For games in particular, the best performance comes if you use a dedicated GPU [1]. Though the CPU emulation can still be a limiting factor.
I'm able to play most 5-10 year old games that aren't tied to DRMs at 30-60 fps on a Pi [2] (and certainly on Ampere) using box64 and an AMD GPU (or Nvidia on an Ampere system), haven't spent much time with FEX-emu though.
I spent some time testing Steam with FEX on the Orion O6 using an AMD RX570. Really surprised it worked as well as it did.
Portal 2 was hitting over 100 FPS. Half-Life 2 and DOOM 2016 hovered around 60 FPS. Shadow of the Tomb Raider and Control mostly stayed above 30 FPS, while The Witcher 3 and God of War usually hung out in the low to mid 40s.
Orion O6 has so much potential, just wish Radxa had a little more focus on just getting one product launched really nicely, instead of spraying out more hardware every couple months.
Venn1 · 1h ago
Indeed, the rollout of the O6 has been disappointing. At least we have two additional companies releasing SBCs with the CD8180, so development won’t be limited to one board.
hackcasual · 1h ago
There's a handful of Windows game emulators taking off for Android. Using a modern snapdragon GPU, folks are playing Witcher 3, GTA 5. Some suffering gamer is playing through Dark Souls 2 using touch controls
3036e4 · 16m ago
Problem is, I assume, being stuck relying on some brittle apps that might or might not still run after some OS upgrade or after buying a new device. Like the DOSBox app I use on my Android phone is amazing but knowing that eventually it will suddenly expire (when the developer abandons it), like the previous one, makes me enjoy the games a lot less than I do when I have a more stable platform set up like when playing using some fully open source emulator on a rpi or x86 desktop pc.
As someone developing HPC applications, I generally don't care either, as long as the hardware has good fundamentals, and is well supported by the available compilers and profiling tools.
Honestly at this point the only reason that I'm aware of to prefer Intel for my workloads is the awesomeness of VTune.
How's the quality of the equivalent AMD or Arm tooling these days?
1) Steam library.
2) And the just works combo of ATX & the ability to use any ISO on almost any x86 machine.
I'm personally scared if x86 dies the open market of ATX and bring your own OS won't exist as every company will just lock you in to only there stuff on their devices.
An open ecosystem in the way that historically emerged around the PC platform seems to be a completely orthogonal issue.
Reminds me when people wanted Intel to die and then they realized AMD started raising their prices with no competition and they tough that maybe AMD isn't their friend and is like any other for profit corporation.
So I have no idea why people want to see the most open PC ecosystem die. What kind of short sighted masochism is this?
Everyone who uses a tablet or smartphone obviously doesn’t care.
Anyone on a Mac doesn’t care, and even on windows, only very performance sensitive people would care if Prism isn’t doing its thing.
You’d essentially be left with AAA PC gamers and other performance sensitive people, which are a small percentage of overall users.
(known as "IPP Everywhere" in the Linux universe)
I edit a ton of 4K video, photos off my Sony Mirrorless, write articles, web, etc.
It is by far the fastest computer I’ve ever used. I have never once known or cared if anything is running x86.
E.g., does it refuse to run on an emulator? Or some bizarre license issue?
I'm able to play most 5-10 year old games that aren't tied to DRMs at 30-60 fps on a Pi [2] (and certainly on Ampere) using box64 and an AMD GPU (or Nvidia on an Ampere system), haven't spent much time with FEX-emu though.
[1] https://www.jeffgeerling.com/blog/2025/system76-built-fastes...
[2] https://www.jeffgeerling.com/blog/2024/use-external-gpu-on-r...
Portal 2 was hitting over 100 FPS. Half-Life 2 and DOOM 2016 hovered around 60 FPS. Shadow of the Tomb Raider and Control mostly stayed above 30 FPS, while The Witcher 3 and God of War usually hung out in the low to mid 40s.
- https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...
Also: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...