[HN Gopher] Arm desktop: emulation
___________________________________________________________________
Arm desktop: emulation
Author : PaulHoule
Score : 79 points
Date : 2025-08-07 12:26 UTC (10 hours ago)
(HTM) web link (marcin.juszkiewicz.com.pl)
(TXT) w3m dump (marcin.juszkiewicz.com.pl)
| ezcrypt wrote:
| 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 wrote:
| 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.
|
| [1] https://www.jeffgeerling.com/blog/2025/system76-built-
| fastes...
|
| [2] https://www.jeffgeerling.com/blog/2024/use-external-gpu-
| on-r...
| Venn1 wrote:
| 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.
|
| - https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-
| th...
| geerlingguy wrote:
| 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 wrote:
| 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.
| hypercube33 wrote:
| God of war runs great on my snapdragon 8 v2 or whatever
| x13s laptop...but gots so hot the GPU clitches since I
| don't think that laptop has active cooling
| ignoramous wrote:
| Tangential: Google engs recently presented RISC-V -> x64 _binary
| translation_ in Android viz. _Berberis_ :
| https://youtube.com/watch?v=HjhzXZqjFrU
|
| Also:
| https://github.com/MattPD/cpplinks/blob/master/assembly.risc...
| CoastalCoder wrote:
| 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?
| testing22321 wrote:
| 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 wrote:
| 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.
| thewebguyd wrote:
| I now want the benchmark for laptop thermals to be time to
| cat.
| testing22321 wrote:
| The difference to my 2015 intel MacBook Pro is staggering.
| Not just speed, but as you said heat, noise and battery
| life.
|
| ARM for laptops is a monster leap forward
| varispeed wrote:
| 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 wrote:
| By what mechanism is Revit locked to x86?
|
| E.g., does it refuse to run on an emulator? Or some bizarre
| license issue?
| varispeed wrote:
| It works on an emulator, but user experience is poor.
| wtallis wrote:
| 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.
| sitkack wrote:
| My favorite unsupported configuration is Homebrew, they
| support Arm-OSX but do not support Arm-Linux and now that
| they have moved to binary downloads, I find it difficult to
| even build the homebrew recipes.
|
| Back when homebrew was source build first and Linux was first
| class, it was the best. Now it has become the thing it
| replaced, MacPorts.
| chainingsolid wrote:
| 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 wrote:
| My hope is that the death of x86 results in everyone flocking
| to RISC-V.
| Joker_vD wrote:
| 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 wrote:
| 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.
| jabl wrote:
| 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.
| FirmwareBurner wrote:
| 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?
| thewebguyd wrote:
| > 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.
|
| I share this fear, and have for a while. x86/the WinTel era
| has offered a lot of computing freedom, both hardware and OS
| wise and I believe we are in real danger of losing that. Not
| just because of an architecture change in isolation either,
| but also with the recent age verification stuff, and pushes
| for requiring "verified platforms" to access certain
| services, we are quickly heading down a proprietary-OS only
| world if you actually want to interact with web services.
| dagmx wrote:
| 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 wrote:
| 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 wrote:
| Isn't there some big standardized/common print driver push
| going on in Windows 11 these days? I wonder if that's
| related.
| jabl wrote:
| There's "driverless" printing in the form of Mopria
| https://en.m.wikipedia.org/wiki/Mopria_Alliance
|
| (known as "IPP Everywhere" in the Linux universe)
| vulcan01 wrote:
| Why is Prism unable to emulate the x86 drivers?
| dboreham wrote:
| 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.
| seabrookmx wrote:
| It's always fun when you peel apart that onion only to
| discover the Docker image was built with a binary blob (.so
| or similar) that's AMD64.
| pacetherace wrote:
| 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.
| bitwize wrote:
| MacBooks, Chromebooks, and Surfaces do not account for all
| consumer computer sales. And there are plenty of x86
| Chromebooks out there.
| rollcat wrote:
| > I'm curious how long until most users just don't care if
| their CPU has native x86 support.
|
| None of the machines I regularly use are x86-native, this has
| been the case for 4 years now. I only care because deploying
| x86 containers is still a thing.
|
| I might be getting a gaming PC at some point, but there are
| very few titles I'm actually really interested in.
| hackcasual wrote:
| 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 wrote:
| 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.
| ekianjo wrote:
| Why ignore box64?
| cogman10 wrote:
| The biggest issue of ARM to me is the fact that ARM hardware
| never seems to have good or updated drivers.
|
| If I pull an x86 machine or even laptop off the shelf, I'm like
| 90% sure I can perpetually support that machine for 30 or so
| years with the latest linux kernel.
|
| For arm, I'm almost guaranteed that the only kernel support I can
| get is their custom kernel, which I'd have to scrape out of their
| custom OS. That means being locked into a vendored 3.10 linux
| kernel forever because there was never any real effort to
| upstream drivers into the kernel.
|
| It's frankly a bit bizarre that it's so bad. x86 just works even
| with the latest CPUs. ARM doesn't.
___________________________________________________________________
(page generated 2025-08-07 23:01 UTC)