GPU Process in Beta 53

A few months ago I reported on an experiment I had run in Firefox Nightly 53 where I compared stability (ie. crashes) between users with and without GPU Process. Since then we’ve fixed some bugs and are now days away from releasing GPU Process in Firefox 53. In anticipation of this moment I wanted to make sure we were ready so I organized a repeat of the previous experiment but this time on our Beta users.

As anticipated the results were different than we saw on Nightly but still favourable. I’d like to highlight some of those results in this post.

Anyone with Windows 7 Platform Update or later with a graphics card that has not previously been blacklisted, and who have multi-process enabled are supported. As it stands this represents approximately 25% of users. Since GPU Process is enabled by default for these users, the experiment randomly selects half of these users and turns off GPU Process by flipping a pref. There is a small percentage of noise in the data (+/- ~0.5%) since flipping the pref doesn’t actually turn off GPU Process until the first restart following the pref flip.

17% fewer driver related crashes

In the grand scheme of things graphics driver crashes represented about 3.17% of all crashes reported. For those with GPU Process enabled the percentage was much lower (2.81%) compared to those with GPU Process disabled (3.54%). While these numbers are low it’s worth noting that all users are not created equal. Some users may experience more driver-related crashes than others based on a multitude of factors (modernity of OS and driver updates, hardware, and mixture of third-party software, etc). It is conceivable, although not provable by this experiment, that the impact of this change would be more noticeable to users more prone to driver related issues. It’s also worth noting that we managed to make this change without introducing any new driver related crashes in the UI process which means Firefox should be much less prone to crashing entirely because of an interaction with the driver, although content may still be affected.

22% fewer Direct3D related crashes

Another category of crashes that sees improvements from GPU Process is D3D related crashes. This category of crashes typically involves hardware accelerated content on the web. In the past we’d see these occurring in the UI process which resulted in Firefox crashing completely. Now, with GPU Process we see about a 1/5th reduction in these crashes and those that remain tend not to happen in the UI process anymore. The end-user impact is that you might have to reload a page but Firefox dies less often.

11% fewer Direct3D accelerated video crashes

More stable hardware accelerated video another interesting benefit of GPU Process. We see about 11% fewer DXVA (DirectX Video Accelerator) related crashes in the test group with GPU Process enabled than the test group with it disabled. The end result of this should be slightly fewer crashes which take down the browser when viewing hardware accelerated video, think sites like YouTube.

Top crashes

Looking at the topcrash charts from Socorro shows expected movement in overall crash volumes. Browser topcrashes are down approximately 10% overall when GPU Process is enabled. Meanwhile, Content topcrashes are up approximately 8% and Plugin topcrashes are down 18%. Topcrashes in the GPU process only account for 0.13% of the overall topcrash volume. These numbers are in line with what we expected based on prior testing.


All of the previous metrics are based on anonymous data we receive from Socorro, ie. crash reports submitted by users. This data is extremely useful in digging into very specific details about crashes but it biases towards users who submit crash reports. Telemetry gives us less detailed information but is better at determining the broader impact of features since it represents a broader user population.

For the purposes of the experiment I compared the overall crash rate for each test group, where crash rate is defined as the number of crashes per 1,000 hours of aggregate browser usage across the entire test group population. The findings from the experiment are interesting in that we saw a slight increase in the Browser process crash rate (up 5.9% in the Enabled cohort), a smaller increase in the Content process crash rate (up 2.5% in the Enabled cohort), and a large decrease in the Plugin crash rate (down 20.6% in the Enabled cohort).

Overall, however, comparing the Enabled cohort to Firefox 52.0.2 does show more expected results with 0.51% lower browser crash rate, 18.1% higher content crash rate, and 18% lower plugin crash rate. It’s also worth noting that the crash rate for GPU Process crashes is very low, relatively, with just 0.07 crashes per 1,000 usage hours. Put in other terms that’s one GPU Process crash every 14,285 hours compared to one Browser process crash every 353 hours.


In the end I think we have accomplished our goal: introducing a GPU process (a foundational piece of the Quantum project) without regressing overall product stability. We’ve reduced the overall volume of some categories of graphics-related crashes while making others less prone to taking down the entire browser. One of the primary fears was that in doing so we’d introduce new ways to take down the browser but I’ve not yet found evidence that this has happened.

Of course the numbers themselves don’t tell the whole story. Now begins a deeper investigation of which crashes (ie. signatures) have changed significantly so that we can improve GPU Process further, but I think we have an excellent foundation to build from.

And of course, watching what happens as we roll out to users in Release with Firefox 53 in the coming days.

57 thoughts on “GPU Process in Beta 53”

    1. We aren’t actively blacklisting any specific graphics cards from using Compositor Process. Basically, as long as you’re on a Windows 7/8/10 system we’ll try to use it. If Firefox fails to initialize the process in a timely manner we stop trying. If the process is running and we detect too many failures the compositor process will be disabled automatically, similar to how Firefox falls back to software rendering for video playback when too many failures in hardware accelerated video playback occur. If you’re using Firefox 53 currently then you’ll know you have a compositor process because you’ll have three Firefox.exe processes in the Windows Task Manager.

  1. I have 3 Firefox processes but i do not have infos in about :support like these ones :
    “Check for the entries GPUProcessPid and GPIPRocess under Diagnostics.”
    So my compositor process is working despite of that?

    1. If you have three processes one of those is most certainly the compositor process. I’m not sure if the diagnostic information in about:support was enabled for Release. That’s something I’d need to verify with the developer.

  2. I’m seeing:

    Compositing Direct3D 11

    GPU #1
    Active Yes
    Description Intel(R) HD Graphics Family

    yet only a single process and:

    Decision Log
    D3D9_COMPOSITING disabled by default: Disabled by default
    GPU_PROCESS unavailable by runtime: Multi-process mode is not enabled

    Can I still enable the GPU renderer?

    1. Unfortunately not as your Firefox does not appear to be running with e10s (ie. multi-process mode is not enabled) — this is a dependency to run GPU Process.

  3. Suggest you blacklist ATI Mobility Radeon HD 4250, as GPU Process really slowed down a flash game (Rail Nation). I had to disable “layers.gpu-process.enabled” in about:config to get the game playable again.

  4. I have:
    – Firefox Version 53.0
    – Windows 10 Pro x64

    System restarted if Firefox open when windows locked (CTRL+L) after 1 hour.

    BSOD ERROR: 0x0000007e (0xffffffffc0000005, 0xfffff80b900015b0, 0xffffb280e26e7878, 0xffffb280e26e70a0).

    WINDOWS DUMP Crash Address: nvlddmkm.sys+3e15b0

    1. This looks like a driver bug and nothing to do with Compositor Process. Please make sure you’re using the latest NVIDIA graphics driver and have all Windows updates installed. If the issue persists you should report it to Microsoft and/or NVIDIA.

  5. I used to think I kept up with things. What does this even mean?

    >”Anyone with Windows 7 Platform Update or later with a graphics card that has not previously been blacklisted,”

    My Win7 x64 Pro W500 Thinkpad has two graphics units- one for electrical efficiency (Intel) and one for more speed (ATI Mobility FireGL V5700).

    1) What is “Windows 7 Platform Update”? I don’t recall seeing that in the updates.

    2) Will the new compositer use my GPU? How can I check?

    3) My system can switch between the 2 Gfx chips while running, on the fly. How will Quantum Compositer react?

    1. > 1) What is “Windows 7 Platform Update”? I don’t recall seeing that in the updates.
      A simple web search for “Windows 7 Platform Update” will get you all the information you need.

      > 2) Will the new compositer use my GPU? How can I check?
      The compositor has always used your GPU. This change puts compositing in it’s own firefox.exe process instead of the main firefox.exe process. Moving the compositor to its own process improves stability (when the compositor crashes it doesn’t take down the whole browser) and has potential performance wins. If you want more details than that I would invite you to post on the Mozilla dev-platform mailing list or in #gfx on

      > 3) My system can switch between the 2 Gfx chips while running, on the fly. How will Quantum Compositer react?
      It shouldn’t react any differently than before. If you find a bug please file it at

      Just to clarify, the Compositor Process part of the Quantum Compositor project; it is not the Quantum Compositor itself. As mentioned earlier, if you have 3 firefox.exe processes then you have the Compositor Process; if you don’t you don’t.

Leave a Reply

Your email address will not be published. Required fields are marked *