Did you know that on Linux, you can already run x86 32 bits software on an ARM 32bits architecture WITHOUT using a Virtual Machine solution such as QEmu? You can do that at very little performance penalty by using [Box86], a piece of software which takes care of translating x86 32 bits instructions in real-time into something that can be understood by an ARM 32 bits processor. It will also take care of interfacing with the right system libraries accordingly so that an x86 binary made for Linux will run seamlessly on an ARM board running Linux. This made it possible to run tons of applications or even (older) games on boards like the Raspberry Pi. This is the work of a single man, PtitSeb, whom I know well since we were both heavily invested in the Open Pandora community (10 years ago now!). Box86 was initially a piece of software that was ideal for running even more games on the Swiss army knife that the Open Pandora is, and now you can use it on every cheap ARM SoC out there.
Since then, PtitSeb has been more busy than ever and has released recently Box64 (Github page), which takes the whole thing to a different level, by supporting the translation of x86_64 processors instructions on ARM64 processors (as always, on Linux). This is the ultimate goal since this opens to door to modern gaming experiences (most binaries for games are made for x86_64 these days), and who knows, potentially Proton for non-native games provided Vulkan compatibility improves on ARM SoCs.
You can see for example the recent retro game Cyber Shadow (GOG version made for x86_64) running on the ARM64 board RADXA ZERO, both with Box86 and Box64:
And here’s Don’t Starve (GOG x86_64 version), running on a Raspberry Pi 4 with Box64 (at about 30fps):
If you like building/strategy games, you will be interested to know that Prison Architect (x86_64 version) runs very decently on ROCKPI4C (RK3399 SoC).
And here’s a compilation where you can see a bunch of games, such as Undertale, SteamDig, Iconoclast, Super Meat Boy, and more, running on the ARM64 board RADXA with Box64:
As you can see the promise of running X86_64 games on Linux ARM64 is not a dream anymore, it’s a reality! Of course, most of the boards out there are too underpowered to run anything but casual/indie titles, so you won’t be seeing a Pi 4 running Metro Exodus anytime soon. But if any manufacturer releases something more powerful… the story could change pretty fast.
We have reached PtitSeb for a quick Q&A on Box64 and where he sees this going forward.
From Box86 to Box64
Boiling Steam: What are the main differences between Box86 and Box64 ?
PtitSeb: Box86 and box64 are very similar. In fact, they are complementary. Box86 targets 32bits linux apps, while box64 targets 64bits apps. That’s the only functionnal difference between them (of course, this implies much more differences internally…)
BS: What kind of hardware is currently supported by Box64 (both on ARM and in terms of AMD64 instructions) ? How much of a WIP is it currently ?
PtitSeb: Any 64bits Little Endian Linux arch could be supported, but for now, I only tested on ARM64. I haven’t used any ARM64 CPU extension yet, so any ARM64 that have Advanced SIMD support will work. I have used Box64 on a Pi4, on many RK3399 boards, on an Odroid N2 board and on a Phytium ARM CPU. It’s also working on Nvidia ARM CPU, like the ones found on the Jetson board, or the Nintendo Switch. The emulated x86_64 CPU has all the minimum expected extensions: FPU/MMX/SSE/SSE2. Also SSSE3. I started a few SSE4.x opcodes, but it is not fully supported yet. Because it is based on Box86 that has a few years of existence, many parts are already stable. Still very much a WIP, as the compatibility is not yet at the level I want it to be.
BS: What were your goals when you started working on Box64 after Box86: did you have any particular project or idea in mind as to what it would make possible?
PtitSeb: My main goal was to run wine64, with a secondary goal to get local server part of Steam running. While I do have Wine64 working now, I still haven’t achieved my secondary goal yet.
BS: To get the local server of Steam running – what is required to make this work?
PtitSeb: Bug fixes it seems. Everything seems to load but crashes eventually. I need to debug this, but it’s a huge program, with a lot of dependencies, mostly emulated libs, and at some point, something goes wrong…
BS: regarding your ongoing work on Box64, is it mainly focused now on accuracy and compatibility, or are there still opportunities for performance improvements too?
PtitSeb: There are a few more opportunities for performances, but I need to focus on compatibility and lib wrapping for the next iterations. Lib wrapping can also bring some speed improvement anyway.
What kind of games can we run currently with Box64?
BS: We have seen games like Shovel Knight, Super Meat Boy, running well now on ARM using Box64. Have you seen anything slightly more demanding that was running using Box64?
PtitSeb: I have Unity3D games running now. While full 3D games like SUPERHOT are too much for current embedded GPU of the RK3399 (2fps is really not enough), simpler games do work nicely (like Race The Sun). I have got games like Train Valley to works too (both 1st and 2nd one). 2D games work fine, like Prison Architect, but some are still a bit slow (GPU may be the bottleneck?) like for Terraria or Starbound. Factorio also starts, but it hits GPU/Driver Bugs and is not displayed correctly for now.
BS: As you focus more and more on Box64, will you keep working on Box86 in parallel ?
PtitSeb: Yes, and because code base is similar, many bug fix/improvements from one can be ported to the other one.
Box64 vs Rosetta2 in Apple land
BS: How does Box64 compare with technologies like Rosetta2 from Apple ?
PtitSeb: Difficult to say I’m not super familiar with Rosetta2. My understanding is that it features an off-line translator (that I assume is triggered when you install x86_64 software) that Box64 does not have. I think it also has a whole set of pre-baked “x86_64” system libraries to avoid the need of wrapping. The CPU translation seems solid from what I have seen.
Box64 and Proton
BS: Many people are wondering, when looking at Box64, whether it will be possible to use this to run Proton with it one day, and therefore play some Windows game through that kind of translation layer. There should be some difficulties around that, such as the availability of Vulkan drivers for said ARM hardware, the Vulkan capabilities coverage, the capabilities of the GPU hardware and so on… what is your point of view on all of that?
PtitSeb: Well, yes, Proton seems the logical extension of my goals: wine64 + Steam… Proton! I haven’t tried yet, I prefer to stay focused on the stuff I already have to fix. And I need to also wrap Vulkan before playing with Proton, as it is not done on Box64 yet. Vulkan is a tricky part for now yes. The Pi4 driver has a Vulkan driver on MESA, but its capabilities are too limited for DXVK. Panfrost Vulkan might be OK, but it’s quite new for now. All the testing I have done on wine (32 bits and 64 bits) shows good performance for OpenGL games (where very little translation is needed), and more mitigated results for DirectX with current Mesa driver on Pi4/RK3399/OdroidN2. Hopefully Vulkan support will evolve to help with Windows games.
The future of ARM offerings
BS: Are you in touch with Pine64? They would probably be very interested by your work.
PtitSeb: I did receive a RockPro64 SBC from Pine64 yes, which is the same hardware as in the PineBook Pro(we reviewed it last year). They did mention Box64 in their last blog post, which is sweet! Radxa had also sent me a few SBCs, the W0 wich can run Box86/Box64 games powered just by a 0.5A USB port (so 2.5W for CPU+GPU+everything!).
BS: Does the availability of Box64 will eventually make it more likely to see ARM hardware used in laptops or workstations? What is your perspective on this?
PtitSeb: Well, Box64 needs to be more stable, and when it will run Steam / Proton flawlessly, then yes, it could help. Apple, with its M1 / Rosetta 2 initiative, showed that with the proper hardware & software combination, you can define an alternative to x86 workstation.
BS: You made a prediction back in February that PCs with powerful ARM chips would see the light of day during this year. Has this become true yet, based on what you have observed?
PtitSeb: Well, I do see a movement yes. Phytium CPUs are getting 8 cores versions, and I have seen that Russian manufacturer has unveiled a new ARM Desktop PC a few days ago. So yes, it’s coming along.
BS: With x86 making some kind of comeback (AMD pushing again for high performance, and Intel investing massively in R&D and lithography and also more powerful integrated GPU with Arc), where do you see the opportunities for ARM SoCs in the laptop/desktop/gaming environments?
PtitSeb: Well, of course it was expected that x86 makers would not let Apple and it’s M1 win over the world without a fight. But the opportunities haven’t changed. And while x86 is not dead yet, a real chance to show that ARM is real alternative now exists, because the public is now aware there is something else available. I think on both laptops and desktops, ARM64 have a chance. And it’s also a political choice: technological independence: ARM licence vs CPU. China and Russia are working on that (not only on ARM, but also RISC-V and probably other architectures too). But for now, only ARM is powerful enough to be a viable alternative.
BS: Do you think it will be possible to hook up Nvidia or AMD GPU graphics cards on ARM hardware in the near future? So far even though the Raspberry Pi 4 compute module has a PCI express port, efforts to make GPU cards work were unsuccessful (probably firmware, memory allocation issues)
PtitSeb: It’s already possible, but not on Pi4. On the Phytium CPU for example, you can (have to in fact) plug an external GPU. Mostly AMD for now, as the driver is Open Source and so is easy to build. Nvidia also has a driver for ARM64.
How to use Box64 in practice?
BS: I have an Odroid Go Advance handheld which uses a ARM64 SoC. How can I get Box64 to run a x86 Linux client game (that uses OpenGL) ?
PtitSeb: I designed box64 to be as much plug’n play as possible. Build is simple and does not require any special dependencies, and it’s stand alone: a binary is enough to be ready to use it (still better to use the small extra: system integration with binfmt and the 2 C++ libs that are widely used). For the Odroid Go Advance, building box64 on the device might be more tricky (need ssh access), and cross compiling can be tricky too. Unfortunately, I don’t own this device, so I have never setup or documented anything about it.
How fast are cheap ARM SOCs vs Intel chips, using Box64 to run benchmarks?
BS: Since you have a translation layer now for x86_64 instructions, is it possible to benchmark how fast is a Raspberry Pi 4 vs an Intel chip on the very same tasks? (non-games – for example file compression, video encoding, etc…) – it could be nice to see how far the Pi4 is from the “regular” intel or AMD chips.
PtitSeb: Yes, I have run CINEBENCH r15, a Wine64 CPU/OpenGL benchmark. The OpenGL bench doesn’t like Panfrost driver (or Pi4 one). But the CPU bench works perfectly. On a Pi/400 with default clock (1.8GHz), I got a CINEBENCH r15 score of 60. Cinebench gives for reference a score of 214 for a Core-i5 3317U at 1.7GHz. So still some work to get to the high performance camp…
Could a future Steam Deck-like machine run on ARM?
BS: You are aware of the Steam Deck from Valve, which uses an AMD APU to play most of the Steam catalogue. How far away are we from having a similar kind of device using a pure ARM64 SOC to run Steam games, on Linux, with Box64 and potentially other projects as needed?
PtitSeb: For now, the GPU part of the ARM SoC I used have always been the weak part. The most flagrant example is the RPi4, that has 4 big cores capable of some nice number crunching, but a really weak GPU that is unable to run anything pushing too many shaded triangles on screen. But with Nvidia’s investment in ARM, this may change. I mean, we know that a Switch, which uses an ARM SoC is already quite capable.
BS: Is there something you would like to ask the community at large to help with Box64? ANy testing needed on more SoCs? Any application you’d like to know if they work or not?
PtitSeb: Testing on more SoC is always welcome. I don’t have any NVidia SoC myself, and I don’t have any Chromebook neither. There are powerful boards coming up, with powerful GPUs too, so some success stories are always welcome!
BS: Do you accept any kind of donations (financial or in hardware) to support Box86/Box64 ?
PtitSeb: Yes, you can donate for box64/box86 development. I have setup a GitHub sponsor page, but there is also a simple Paypal donation option. For hardware, my mail address is not public so you need to contact me first for this.
We will be following Box64 very closely at Boiling Steam – this has the clear potential to be a game changer, maybe not in this year, but in the very near future, as Apple has shown how great the opportunity can be. In any case it’s very healthy to be in a more competitive market not just dependent on x86 for everything.
Except this to make big waves.
BoilingSteam lets you access our content for free, but writing articles is a constant investment. We don't use ads or sponsporship, help us make our activities sustainable by donating via Patreon or LiberaPay if you prefer it anonymous. You can follow what we do via our newsletter, our RSS feed, our Mastodon profile or our Twitter feed. We also have Peertube, Youtube and LBRY channels. If you'd like to chat, you can also find us on #boilingsteam:matrix.org. (what is Matrix?)