Chromium Power ISA patches ... from Solid Silicon


It appears that some of the issues observed by me and others with Chromium on Fedora ppc64le may in fact be due to an incomplete patch set, which is now available on Solid Silicon's Gitlab. If your distro doesn't support this, now you have an upstream to point them at or build your own. They include the Ungoogled changes as well, even though I retain my philosophical objections to Chromium, and still use Firefox personally (I've got to get back on the horse and resume maintaining my personal builds now that I've got Plasma 6 back running on Xorg again).

Oh, yeah, it really is that Solid Silicon. You can make your own speculations from the commit log, though regardless of whether Solid Silicon is truly a separate concern or a Raptor subsidiary, it wouldn't be surprising that Raptor resources are assisting since they've kind of bet the store on the S1.

Timothy Pearson's comments in the Electron Github suggest that Google has been pretty resistant to incorporating support for architectures outside of their core platforms. This is not a wholly unreasonable position on Google's part but it's not a particularly charitable one, and unlike Mozilla, the Chrome team doesn't really have the concept of a tier-3 build nor any motivation to. That kind of behaviour is all the more reason not to encourage browser monocultures because it's not just the layout engine that causes vendor lock-in. Fortunately V8, the JavaScript engine, is maintained separately, and reportedly has been more accommodating presumably because of things like Node.js on IBM hardware (even IBM i via PASE!).

Mozilla is much more accepting of this as long as regressions aren't introduced. This is why TenFourFox patches were largely not upstreamed since they would potentially cause problems with Cocoa widgets in later versions of macOS, though what patches were generally applicable I would do so. The main reason I'm still maintaining the Firefox ppc64le JIT patches outside is because I still can't solve these recent startup crashes deep within Wasm code, which largely limits me to Baseline Compiler and thus is not suitable for loading into the tree yet (we'd have to also upstream pref changes that would adversely affect tier-1 until this is fixed). I still intend to pull these patches up to the next ESR, especially since Github is glacially slow now without a JIT and it's affecting my personal ability to do other tasks. Maybe I should be working on something like rr for ppc64le at the same time because stepping through deeply layered code in gdb is a great way to go stark raving mad.

Comments

  1. Thanks for the updates, I was curious what's the state of things on the Firefox side.

    ReplyDelete
  2. We do have the equivalent of Tier 3 builds; the gcc build is such a case.

    We also do take patches outside our core platforms, but subject to pretty strict analysis of the costs and benefits. For example, there are some mips and (iirc) ppc patches in the tree, but only in places where adding those doesn't increase the existing complexity at all, because there's already an abstraction later there. And I've landed patches to improve msvc support (which we don't build with), but only where it's clear msvc is being standard-compliant and doing things compatibly with them improves the code.

    This isn't as nice as what a lot of folks would like, but I don't think it's as black as what's portrayed here.

    ReplyDelete
  3. I believe Keno Fischer at one point had a semi-working port of rr to ppc64le (Linux of course). You might want to ask him about it.

    ReplyDelete

Post a Comment

Comments are subject to moderation. Be nice.