Happy new year, and happy new release of Box64!
The new version brings a ton of new enhancements and fixes to all 3 supported platforms, with Steam running not only on Arm64, but also on RiSC-V and on Loongarch! And this is the Linux version of Steam, not the Windows one (but the Windows one works too if you really prefer that one). While Box32 (used to run Steam) is still experimental and unstable, stability did improve. Still, expect some crashes when downloading things with steam. And it’s not all, Battle.net is also getting stable, and some games are working too. Not all unfortunately, and your success might depend on your geographical region, as program versions might differ. At least, you can try it on ARM64 & Loongarch. It’s still to be tested on RiSC-V.
Highlights
So, what’s new in this release? Apart from the traditionals fixes, speedups, opcodes implementation and new wrapper functions, there has been a number of refactors. Some are more groundwork for later use, like the libdl one. But some have immediate benefits. The prefix opcode decoder, now implemented on the interpreter and the 3 dynarec backend is one of those. This allows to more generically handle exotic opcode prefixes without doing hacks or adding duplicated code. This one lead to the removal of many source files, now useless, making the maintenance of box64 a bit easier. Also, this automatically added support for many rare (or less rare) occurrences of many opcodes in the Dynarec, with 0 extra coding.
There has been some work on the memory footprint of box64 too. Some applications use a lot of memory once launched with box64 (Steam for example, or other things that use libcef or a variant of it). So some work was started to develop mechanisms to try to identify blocks of code that have been converted to native, but that seem to not be used anymore, so they can be deleted and the memory recycled for some fresh code. The work is still in progress on this subject, and more work will come in next release.
Capture card
I have (finally?) invested in a capture card (an Elgato HD60X) for all my video capture. I did all the Loongarch & RiSC-V game captures using OBS on my Ampere ARM64 machine (plug’n play), and I did the Ampere game footage captures using a Lenovo T14s (XElite/ARM64) running Ubuntu also with OBS. While the capture done on the Ampere (using the NVidia card and encoder) were fine, the ones done on the T14s (using software encoder) were a little too compressed for many captures. I have adjusted the settings, but not redone most of them, so you will see some compression artefacts in the ARM64 gameplay video. But at least the performances are not hurt by the capture anymore…
Side note: the editing was also done on the Ampere ARM64 machine (with OpenShot), so no x86 machine was involved in those videos at all!
Architectures
While there is not much news on the ARM64 side (there is added support for the GB10 cpu as a build profile for Box64), there was still some refactoring to improve performances of the Dynarec there. There is still ongoing work to detect and optimize more code loops; for instance, pre-loading used XMM/YMM register just before entering the loop, to avoid loading and saving these registers when it’s not needed. That can give some big speedup in some case. More speedup will be expected when more loop cases are getting detected and handled.
On the RiSC-V, the last months have brought the Dynarec to a very decent level of completion and performances, thanks to contribution of PLCT Labs and many things are working now. Steam, Proton and Wine are all running (even with the 39bits address space limitation of many hardware). But DRM protected stuff that need Windows Syscall emulation will not work for now unless the hardware support SV48 (48bits address space) or using a hacked Wine/Proton. The current hardware used for the video is a Pioneer Milk-V mini-server and its 64 cores CPU. But each core is still quite slow, at 1.5GHz, and the equipped graphic card, an old AMD RX550, is also showing it’s limitation in some of those videos…
The Loongarch backend is the one that saw the most progress in this cycle, and this CPU is starting to shine already, even if the Dynarec doesn’t yet have all the bells and whistles from the ARM64 version. Steam works now, but also Wine and Proton. But you need to use the 4K page size kernel. The default for this system is usually 16K, but most OS have a 4K option. I use AOSC on my side, but there is now a Debian option too. The modest 3A6000 is a 4 physical cores (8 logicals cores) CPU at 2.5 GHz. Sounds modest on paper, but equipped with a good AMD RX7600, the results are already quite surprising. And it seems to be even better on more powerful variants of the CPU, like the 3B6000 (12 cores) or 3C6000 (16 cores).
ESync / FSync / NTSync
Wine and Proton need some complex synchronisation mechanisms between processes. By default, Wine uses a basic system on the wineserver side. It works but can be quite slow depending on the number of processes / threads / CPU cores… So various mechanisms have been developed in the last few years. The first two are ESync and FSync. While they can be faster, they can also be not 100% accurate. Box64 supports both of them (and they get used automatically by Proton in Steam), but some games are not synchronising correctly when using them. Games that use the Rockstar launcher or Microsoft XBox services might not start correctly when using ESync and FSync on ARM64. So on steam, you might need to use
PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1 %command%on the program launch option in steam. Or disable them using the UI if you are using Heroic.
NTSync on the other hand seems to work fine, but is very new. You need to have a kernel where NTSync is enabled to use it. Debian on ARM64 still hasn’t that, even on the Forky branch. Ubuntu on ARM64 seems the same. Both OS on X64 ship kernels with NTSync enabled it seems. Armbian, on the other hand, have kernel with NTSync enabled. On Loongarch, AOSC also has NTSync enabled. Note that you need a bleeding edge Wine or Proton-GE to actually use NTSync. The default Proton from Steam will not use it for now, so it’s very early, but some result on 3C6000 processor shows some impressive result with about 80% more FPS in heavy games.
Conclusion
Box64 is ready to be used, so go grab the source, build your own version and enjoy!