Posts

Showing posts with the label Start Me Up

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.

First production Kestrel and Arctic Terns? (OpenPOWER compute modules exist!)


Thanks, D, who's quicker on the draw than I am: this image popped up on the Raptor Wiki. Looks like Kestrel and Arctic Tern made it to full prototyping, and maybe on the way to production!

This image shows a Blackbird being brought up solely with the Kestrel soft BMC (the metadata says the ASPEED BMC was completely disabled), powered by a much more advanced design than the ECP5 card we saw in the last iteration, especially because this is now a set of custom boards. The PCIe carrier card has Ethernet and two HDMI ports to the left, and what looks like JTAG and serial (grey ribbon) on the right near the LEDs. The "hat" board has been incorporated into the carrier with the LPC, FSI (the black cables curling around out and back into frame go to the connector next to DIMM A1) and I2C signals, and a separate ribbon cable carries the TPM lines.

So far, this is mostly just moving components around. But new on this carrier card are two SO-DIMM style module slots, both populated with what looks like the same sort of card, though only the top one seems to be active. These modules are labeled "ARCTIC TERN ECP5 MODBMC (?) CARD AT1MB1 REV 1.01 (C)2022 RAPTOR COMPUTING SYSTEMS, LLC" (there was a rev 1.0? what did we miss?). This is clearly the CPU card on which the Kestrel soft BMC software runs. The BMC flash likely lives on these boards, but not the PNOR, which appears to be on flash chips on the carrier to the left of the LEDs. UPDATE: this thread says the modules have 1GB of DDR3 RAM each (!), and the CPU fan is directly connected to the carrier. They can be accessed remotely.

It really looks like it may be shipping in the very near future and I'm jazzed about how fast Kestrel reportedly can bring the system to power-ready. But there are two more exciting things about this: first, if this is laid out the way it appears to me to be, this means you can have two BMCs for a libre dual-monitor setup right out of the box, no extra PCI cards or firmware blobs required. (Suck it, Nvidia.) Second, and even more notable, this means that OpenPOWER compute modules may soon be a thing! Given Raptor Engineering, I'm sure hoping these will be sold for standalone projects, especially if the onboard Microwatt-core performance is competitive with RPi and other ARM boards. Maybe then the people whining about how much it costs to play with OpenPOWER will finally get something at a lower price point to play with (and then they can complain about that).

That said, we still don't know price or availability yet, and we don't know if there will be a way to add a Kestrel setup without using a precious PCIe slot (after all, the T2 Lite has only three, and the Blackbird just two; hopefully it can be configured to pull power from something else). But there's a lot of good things in this picture and we're looking forward to hearing more in what are no doubt soon-to-come official announcements.

Firefox 95 on POWER


Firefox 95 is released, screenshot at right. The big new feature, besides speculative AOT JIT which doesn't apply to us yet, is RLBox, which compiles certain third-party libraries into safe WebAssembly, and then compiles them back into C, so they can be compiled a third time into pre-sanitized native code. This has obvious security benefits and the performance impact shouldn't be especially large, but it adds yet another build-time prerequisite: the WASI SDK. This kind of really sucks because now you have to have a third toolchain (it builds one whether you like it or not) besides clang and our preferred compiler, gcc. Pending internal package support, some distros have chosen simply to disable this for the immediate future, even including Fedora.

Besides the inconvenience the other main issue with this is while it's clearly safer native code, it's also slower native code by some non-zero factor, however small in a well-optimized PGO-LTO build. As such I've chosen to test to make sure it works but my "official" PGO-LTO build configs will have it turned off for the time being with --without-wasm-sandboxed-libraries. While it was very easy to build the smaller WASI libc, it doesn't have C++ headers, so the build goes bang if you try to use it as a WASI sysroot. Fortunately you can download a pre-built copy of the SDK and just pull out the system-independent wasi-sysroot and feed that to the Firefox build system with --with-wasi-sysroot=/where/it/at/wasi-sysroot. Then, to get the built-ins for linking pull out libclang_rt.builtins-wasm32.a and copy it to /usr/lib64/clang/13.0.0/lib/wasi (or wherever your clang libraries reside), and ensure you have wasm-lld. You may have to install lld to get wasm-ld; I had to, but Fedora has a package for it already. Now that you've looted the archive, you can just trash the rest of it and use your system version of clang assuming it's version 8+. This works and makes a functional version of Firefox but I can totally understand why this is unacceptable if you want to build from the raw source code.

After all that, though, I'm running Firefox 95 without RLBox simply because we need to wring all the performance out of the executable that we can. As such, here are the current .mozconfigs.

Debug

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24" # or as you like
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-Og -mcpu=power9 -fpermissive"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd
ac_add_options --without-wasm-sandboxed-libraries

export GN=/home/censored/bin/gn # if you haz

Optimized

export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

mk_add_options MOZ_MAKE_FLAGS="-j24"
ac_add_options --enable-application=browser
ac_add_options --enable-optimize="-O3 -mcpu=power9 -fpermissive"
ac_add_options --enable-release
ac_add_options --enable-linker=bfd
ac_add_options --enable-lto=full
ac_add_options --without-wasm-sandboxed-libraries
ac_add_options MOZ_PGO=1

export GN=/home/censored/bin/gn
export RUSTC_OPT_LEVEL=2

The PGO-LTO build patch is also updated.

Oh, by the way, in JIT news, I've mounted a debug browser and OpenPOWER Firefox can now run Doom. (Firefox 91 ESR shown.)

Still some glitches to work out, some of which I suspect aren't anything to do with Wasm support, but you couldn't do this on Firefox on OpenPOWER before. Does this count as a "Tonight's Game on OpenPOWER" entry? (*Firefox 2.0.0.20 on Windows 95 screenshot from Beta Archive.)