Latest Posts

Fedora 39

Fedora 39 is out, the Linux distro I use personally on my Talos II and Blackbird systems. Since I'm doing a lot of remote work with the new $DAYJOB it might be a bit before I can sit down with it but there will be the usual mini-review (here's what I had to say about Fedora 38). This release is based on kernel 6.5 and GNOME 45, with LLVM 17, Perl 5.38, glibc 2.38 and gcc 13.2. As usual, Fedora 37 will EOL one month after this release.

However, F39 isn't really the big news, and probably won't be a very exciting (or bumpy) release. Instead, the bigger and possibly more obnoxious change will occur with Fedora 40 when the Plasma spin (which I use instead of GNOME) is expected to completely drop X11 support, and the same is likely coming for GNOME 46 which will occur in the same version. It will be interesting, to say the least, to see how this affects people running OpenPOWER systems without GPUs to be completely blob-less. I've not been terribly happy with Wayland on the Blackbird's ASpeed BMC framebuffer and I haven't seen anything to indicate that its deficiencies have improved. Wonder how well it would work on the X1 ...

Firefox 119 and the next ppc64le JITeration

Although I've been a bit preoccupied lately with a new $DAYJOB which has required me to be remote, let's not bury the (larger) lede: the first iteration of the Firefox/SpiderMonkey ppc64le JIT is being evaluated by Mozilla to determine if the changes are acceptable. Please don't spam the Bugzilla entry with drive-by comments, but if you'd like to observe its progress, you can follow along in bug 1860412.

That doesn't mean, of course, that you can't try it yourself. The current JIT state for 115ESR now supports baseline Wasm as well as full optimizing Ion compilation for regular JS, and passes the complete test suite on Linux. It does not yet support POWER8, nor the optimizing Wasm compiler, so some applications will not run as well as they should (and obnoxiously asm.js code is not JITted at all in this configuration because it relies on the optimizing Wasm compiler, despite the fact it's regular JavaScript — for TenFourFox, which didn't support Wasm otherwise, I hacked JavaScript to simply compile asm.js with regular Ion). However, I do intend to add support for optimized Wasm and later POWER8, and with that said, the testers I've been seeding this with see good improvements for the vast majority of sites and no additional reproducible crashes so far.

If you'd like to give it a shot as well, then apply the new patches numerically and build as we did for Firefox 115, using the .mozconfigs from Firefox 105. For your convenience the JIT patch set already includes the PGO-LTO and WebRTC fixes for that version. If you don't want to roll your own browser (though I highly recommend it), then Dan Horák has you covered with a copr build for Fedora users. However, I don't intend to backport POWER8 or optimizing Wasm support to 115ESR; future work will be done on trunk, assuming Mozilla is fine with the existing changes. Do not post bugs with the ESR JIT to bug 1860412.

Apart from that, the other Firefox news is anticlimatic: Firefox 119 (I did a test build of Fx118 but hadn't tested enough to post about it) builds fine with the WebRTC patch from Fx116 (or --disable-webrtc in your .mozconfig), the PGO-LTO patch from Fx117 and the .mozconfigs from Firefox 105.

The next Raptor OpenPOWER systems are coming, but they won't be Power10

I'd like to first start out by saying I've been aware of new developments but made certain promises to keep my mouth shut until all the parties were ready to announce. (Phoronix is not so constrained.) Many of you noted an offhand comment in this YouTube video about Raptor announcing a new Power10 system. That got a lot of people excited, because while our POWER9 systems are doing well, in 2023 this dual-8 64-thread POWER9 is no longer cutting edge and we need new silicon in the pipeline to keep the ecosystem viable.

Raptor yesterday officially announced that we're not getting Power10 systems. The idea is we're going to be getting something better: the Solid Silicon S1. It's Power ISA 3.1 and fully compatible, but it's also a fully blob-free OpenPOWER successor to the POWER9, avoiding Power10's notorious binary firmware requirement for OMI RAM and I/O.

I asked Timothy Pearson at Raptor about the S1's specs, and he said it's a PCIe 5.0 DDR5 part running from the high 3GHz to low 4GHz clock range, with the exact frequency range to be determined. (OMI-based RAM not required!) The S1 is bi-endian, SMT-4 and will support at least two sockets with an 18-core option confirmed for certain and others to be evaluated. This compares very well with the Power10, which is also PCIe 5.0, also available as SMT-4 (though it has an SMT-8 option), and also clocks somewhere between 3.5GHz and 4GHz.

S1 embeds its own BMC, the X1 (or variant), which is (like Arctic Tern) a Microwatt-based ISA 3.1 core in Lattice ECP5 and iCE40 FPGAs with 512MB of DDR3 RAM, similar to the existing ASpeed BMC on current systems. X1 will in turn replace the existing Lattice-based FPGA in Arctic Tern as "Antarctic Tern," being a functional descendant of the same hardware, and should fill the same roles as a BMC upgrade for existing Raptor systems as well as the future BMC for the next generation systems and a platform in its own right. The X1 has "integrated 100% open root of trust" as you would expect for such a system-critical part.

Raptor's newest systems are planned for late 2024. There will be tiering, so most likely (though not confirmed) Blackbird, T2 and T2 server classes of systems will be available under new names. Price? Well, you'll just have to wait and see.

Solid Silicon is definitely a new name in the Power ecosystem and we don't know a lot about them. There's a web page, but the TwXitter and LinkedIn links are unpopulated as of this writing, and it's maddeningly minimal on actual content. Tim confirmed they are a new licensee and have been working on the design for at least a couple years. The press release gives a 737 area code, which is Austin, Texas, and the only Solid Silicon business entry I could find for Texas is this one for Solid Silicon Technology LLC in Plano. I'm told this isn't them, so if anyone from Solid Silicon would like to lift the corporate veil a little, drop me a line at ckaiser at floodgap dawt com. [UPDATE: The LinkedIn was updated after this posted, listing Todd Rooke as CEO. Rooke's listing indicates past experience with FPGAs, as well as his time at HPE and Microsoft. His location is given as Colorado Springs but Colorado lists no company by that name. Hopefully more to come.]

But besides new systems in the offing, it's also good news that we're getting — we hope — performant OpenPOWER chips that aren't from IBM. I don't have anything against IBM; I've worked with IBM hardware for literally decades, and my home server is a classic POWER6 that just keeps on truckin'. But IBM designs chips to benefit IBM's world, which is server rooms (ask anyone who's got one what it's like to share an office with a POWER8), and IBM doesn't do end-user sales. If Raptor has a good partner here who can design solid OpenPOWER chips for workstations and small servers, not traditionally IBM's present domain but one important for them to maintain if they want OpenPOWER to stay relevant, then in around a year we should be in for a treat — and a very rosy near future.

OpenBSD 7.4

OpenBSD 7.4 is released, an increasingly mature BSD option for OpenPOWER systems. While there are relatively few improvements this time around specifically for the powerpc64 port, this release does have improvements for SMP (a big deal for our pervasively SMT cores), performance and security upgrades with the virtual memory manager, and updates and bugfixes to userland. You can download it, or read the entire changelog.

Progress on the Firefox ppc64le JIT

A picture is worth a thousand Wasm opcodes. This is further along than we've gotten on earlier drafts. More soon.

Partial ppc64le JIT available again for Firefox 115ESR

I've been rehabilitating the old ppc64le JIT against more current Firefoxes and there is now available a set of patches you can apply to the current 115ESR. This does not yet include support for Ion or Wasm; the first still has some regressions, and the second has multiple outright crashes. Still, even with just the Baseline Interpreter and Baseline Compiler it is several times faster on benchmarks than the interpreter-only 115. I've included also the relevant LTO-PGO and WebRTC patches so you can just apply the changesets numerically and build. The patches and the needed .mozconfigs for either building an optimized browser or a debug JS shell (should you want to poke around) are in this Github issue.

While this passes everything that is expected to pass, you may still experience issues using it, and you should not consider it supported. Always backup your profile first. But it's now an option for those of you who were using the previous set of patches against 91ESR.