Firefox 67 on POWER


Firefox 67 has been released and to my relief (though I now build smoketest builds of Firefox on ppc64le approximately weekly to find such problems) mostly builds uneventfully. It has a number of nice features, including enhanced content blocking, improved full keyboard accessibility and various performance improvements. The marquee GPU-accelerated WebRender isn't on most Linux systems yet but that's coming soon, hopefully. I haven't experimented with it yet myself but the existing GPU acceleration works fine on this Talos II with the BTO AMD WX7100 card (set layers.acceleration.force-enabled to true in about:config).

That brings up the first catch, because I did say mostly uneventfully: changes to profile handling. If you build from mozilla-release as I do and I recommend, you will end up with a "nightly release" version (assuming you don't pass --enable-release, which I advise you don't pass right now). Starting with Fx67 nightlies from any tree will try to create a new profile separate from your previous profile but the old one remains intact. You can explicitly select it from the Profile Manager (pass -P), or, if you know already which profile you want to use, you can specify it with -p (on my system the default profile is unimaginatively called default, ergo, -p default).

The second catch I haven't figured out the cause, whether it's a kernel or a Firefox bug, but periodically it will throw occasional but not infrequent warnings that look like this in dmesg (this is on a 5.0.x kernel):

[337262.237052] ida_free called for id=170 which is not allocated.
[337262.237089] WARNING: CPU: 6 PID: 12276 at lib/idr.c:519 ida_free+0x114/0x1e0

If you are on a distribution where kernel warnings get converted into notifications (like the Fedora machine I'm typing on), this can be rather obnoxious. If you are badly afflicted, you can temporarily turn them off with these instructions. I haven't found the root cause for it yet and it's hardly a great hardship, but it didn't occur in Firefox 66.

As far as the Firefox JIT for POWER9, I'm still plugging along, but other than a minor pull request to the documentation it's still 100% yours truly working on it. Of the remaining pieces the macro assembler is about 2/3rds written, leaving the low level assembler after that, and then trying to make it build. However, I'm also in the midst of a systems update for TenFourFox, which I still have a commitment to maintain in the short term, so any help will get it in your hands faster. Hopefully the commits make it clear how I'm translating the MIPS backend into POWER9, using all that 3.0B goodness (population count instructions! trailing zero count instructions! load PC in one instruction! it's an assembly language candy store!).

It's been a little while since I posted the .mozconfigs I use, so rather than direct you to old entries I'll just reproduce them here. Note that MOZ_PGO and MOZ_LTO don't seem to properly work and may generate defective binaries, thus their absence, and I explicitly pass --disable-release to an opt build because of various minor problems which hopefully we'll eventually smoke out. Adjust the number of cores as you like; this is a dual-4 system, so with 32 threads available I reserve 8 to let me still play Descent II during build runs. :)

Debug

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="-Og -mcpu=power9"
ac_add_options --enable-debug
ac_add_options --enable-linker=bfd

export GN=/usr/bin/gn # if you have it
export RUSTC_OPT_LEVEL=0

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"
ac_add_options --disable-release
ac_add_options --enable-linker=bfd

export GN=/usr/bin/gn # if you have it
export RUSTC_OPT_LEVEL=2

Comments

  1. Your mention of 3.0B goodness warns me that your asm/JIT will then not work on POWER8. No offence I'm just checking that someone then needs to make some work on porting POWER9 -> POWER8 here.

    ReplyDelete
    Replies
    1. My understanding is the target is indeed POWER9 first, which is good from my perspective in that we need to look forward and to being able to run JS as fast as x86 machines, not backward to POWER8 if it means we can't use the new instructions and would lose interpreting speed. POWER8 can always be added later on, POWER9 is the majority deployment of desktop OpenPOWER as far as I am aware.

      Delete
    2. Yeah, that's a problem - that will also make it unshippable out of box in pretty much any distribution, as packages that only work on specific hardware are a big no.

      Delete
    3. Yes, the plan is POWER9 first (see the README in the github repo). There are two reasons.

      The first is that with the new instructions in 3.0B, not only can speed benefits be achieved but also it makes the first draft less buggy because we don't have to write equivalent sequences that we might get wrong. This was a big issue for TenFourFox, where some of the sequences turned out to have subtle issues that took a while to figure out. I don't want to repeat this if I can avoid it.

      The second is simply I don't have any POWER8 hardware to develop or debug on (before anyone jumps in and offers, I would rather be doing this on a local machine).

      TenFourFox used a multi-architecture JIT and the same can be done here. On G5, for example, which has fsqrt, it just uses that; on G3 and G4, it uses an equivalent sequence with frsqrte and a couple converging iterations. The same situation happens here: on POWER9 a single instruction can be used and on POWER8 an equivalent sequence.

      What will happen after the first draft when Firefox + POWER9 JIT is compiled on a POWER8 is no JIT, same as currently. The goal is, as POWER8 equivalent sequences are added, a default to build a POWER8-compatible JIT but POWER9 optimizations can be selected via the compiler or runtime detection as appropriate.

      Delete
  2. Seems the new Firefox 67 in Fedora doesn't suffer from the crash when typing in the URL bar, that's good :-)

    ReplyDelete
    Replies
    1. Yes, although my machine freaked out yesterday (doing anything, not just Fx67), so I'm forcing a full update to F30 a little earlier than planned. It smells like a kernel problem I'm tickling.

      Delete
    2. I'm already running F-30 for 2 weeks, no (new) problems so far. There was one with rebased "orc", but I fixed that.

      Delete

Post a Comment

Comments are subject to moderation. Be nice.