Tonight's game on OpenPOWER: Death Rally

Let's go for another shooter, but this time a top-down one. Essentially a murderous Super Sprint, Finnish developer Remedy's first game was the exuberantly zippy Death Rally, a decidedly socially hostile top-down racer with machine guns, bombs, spikes, sabotage, splattable spectators and cold hard cash. You can pick up missions for extra money (assassinations, drug running, the usual) or just exterminate your competition for a big bonus and plow the proceeds into a better chassis, a faster engine and better tires and armour. Apogee picked it up and added Duke Nukem for extra competition along with Remedy's cadre of obviously named parody racers (just try to guess who Bogus Bill is).

While Death Rally plays well in DOSBox, and even got an official freeware Windows port, there was never a Mac version (I had to play it on my beat-up old 486) and it was never open-sourced. A few attempts have been made to decompile it but the best of these is dRally, which is 64-bit compatible and compiles out of the box (just make -j24 or as you like for your number of cores) with SDL2 on Fedora 35. The old IPX multiplayer mode isn't supported but everything else mostly works.

Once it's compiled, you'll need a copy of the game assets, of course. I have the GT Interactive retail CD; I have not tried to extract it from the Steam version, 3D Realms no longer sells it directly, and I can't find it on GoG, so let's assume you've got a disc too. For that, just copy over all the *.BPA files (make sure they remain uppercase!) and the CINEM subdirectory from the CD. Create a file called CDROM.INI that simply has one line, ./CINEM (to tell it where the movies are). Start the game in that directory (I made a directory called assets that has everything in it and just symlinked ../drally_linux for convenience).

There are two bugs I ran across, neither serious. The DOS game alternates between 640x480 and a letterboxed (in SDL) 320x200 mode; the former is used for menus and the latter for videos and actual gameplay. On my Talos II in Fedora 35 with a WX7100 there's a lot of garbage in the letterboxed area which can be improved, though not completely eliminated, with this patch. Also, at least with my GT retail copy, if you let the game sit at the menu too long it will eventually go through its brag screens and crash when it hits one that doesn't seem to be in the archive. This patch wallpapers the problem.

Otherwise, I've been gunning down other cars all afternoon, and I haven't had to fire up DOSBox to do it. Get ready to go!

Attack of the zombie PowerVR GPUs

Like rotted silicon corpses, several new recent GPU cards based on Imagination Technologies' old school PowerVR IP have emerged in the Chinese market, including the Innosilicon Fantasy One series and most recently the Moore Threads MUSA family. Don't kid yourself either about these being particularly more open than AMD and Nvidia offerings, though support for the Rogue GPUs is landing in kernel and in Mesa3D; while there is fairly good documentation on the GPU's ISA the firmware is still likely to be binary blobs (though this is no worse than the alternatives). Moreover, their performance even from the OEM specs just isn't competitive with current cards. That said, any GPU at all beats the flat framebuffer of the ASTs in our systems, and these chips may move more slowly enough to be more stable in the kernel compared to the occasional churn with amdgpu and friends. Assuming it can be flexible on page size, another alternative GPU architecture, even a basic one, would be welcome (at least until the Microwatt-based Libre-SoC is a viable option). We'll be watching that space.

Firefox 99 on POWER

Firefox 99 is out. The major change here is that the Linux sandbox has been strengthened to eliminate direct access to X11 (which is important because many of us do not live in the Wayland Wasteland). Note that the sandbox apparently doesn't work currently on ppc64le; this is something I intend to look at later when I'm done with the JIT unless someone™ gets to it first.

Unfortunately, Fx99 does not build from source on ppc64 or ppc64le and I was too busy on the JIT to do my usual smoke tests early. The offender is bug 1758610 but the patches do not apply cleanly to 99, so I have provided a consolidated diff for your convenience. You will also need a tweaked PGO-LTO patch; with those applied the .mozconfigs from Firefox 95 will work.

All three stages of the JIT (Baseline Interpreter, Baseline Compiler and Ion, as well as Wasm) now function and pass tests on POWER9 except for a couple depending on memory layout oddities; that last unexpected test failure took me almost a week and a half to find. (TenFourFox users will be happy because a couple of these bugs exist in TenFourFox and I'll generate patches to fix them there for source builders.) However, it isn't shippable because when I built a browser with it there were regressions compared to Baseline Compiler alone (Google Maps fonts look fuzzier in Ion, the asm.js DOSBOX dies with a weird out of range error, etc.). The shippable state is that Ion should be a strict superset of Baseline Compiler: it may not make everything work, but anything that worked in Baseline Compiler should also work with Ion enabled, just faster. These problems don't seem to have coverage in the test suite. You can build the browser and try it for yourself from the new branch, but make sure that you set the Ion options in about:config back to true. Keep in mind that this is 97.0a1, so it has some unrelated bugs, and you shouldn't use it with your current Firefox profile.

Smoking out these failures is going to be a much harder lift because debugging a JIT in a heavily multi-threaded browser is a nightmare, especially on a non-tier-1 platform with more limited tooling; a lot of the old options to disable Electrolysis and Fission seem to be ignored in current releases. With that in mind and with the clock counting down to Firefox 102 (the next ESR) I've decided to press on and pull down Firefox 101 as a new branch, drag the JIT current with mozilla-central and see if any of the added tests can shed light on the regressions. A potential explanation is that we could have some edges where 32-bit integer quantities still have the upper word set (64-bit PowerPC doesn't really have comprehensive 32-bit math and clearing the upper bits all the time is wasteful, so there are kludges in a few places to intercept those high-word-set registers where they matter), but changing these assumptions would be major surgery, and aside from the delays may not actually be what's wrong: after all, it doesn't seem to break Baseline. One other option is to deliberately gimp the JIT so that Ion is never activated and submit it as such to Mozilla to make the ESR, and we'd have to do this soon, but indefinitely emasculating our Ion implementation would really suck to me personally and may not pass code review. I'm sure I've made stupid and/or subtle errors somewhere and a lot of code just isn't covered by the test suite (we have tons of controlled crashes, asserts and traps in untested paths, and none of it is triggered in the test suite), so I really need more eyes on the code to see what I can't.