1925776 - “Failed to create EGLSurface, Fallback WR to SW-WR” when opening many windows

Status: UNCONFIRMED

(Core :: Graphics: WebRender, defect, P3)

Description

[Yuri Khan]

Attachment: about:support data

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:131.0) Gecko/20100101 Firefox/131.0

Steps to reproduce:

Ubuntu 24.04, Firefox 131 deb package from ppa:mozillateam/ppa.

0. Started from a terminal emulator: firefox -ProfileManager.
1. Created a new profile.
2. about:preferences → General → Startup: checked the Open previous windows and tabs box.
3. Opened about:about.
4. Starting from about:addons, and up through about:processes, shift-clicked each link.
5. Exited Firefox by pressing Ctrl+Q and confirming.
6. Re-started Firefox by repeating the firefox -ProfileManager command in terminal, choosing the same profile.

Actual results:

At some point during step 4, Firefox outputs the following to the terminal:

[GFX1-]: Failed to create EGLSurface!: 0x3003
[GFX1-]: Failed to create EGLSurface. 25 renderers, 1 active.
[GFX1-]: Handling webrender error 3
[GFX1-]: Fallback WR to SW-WR

In step 5, the same error messages appear.

After that error, about:support reports “Compositing: WebRender (Software)”, which I interpret that it’s not hardware accelerated, possibly working slower and/or consuming more battery.

The error seems to be directly connected with the number of windows rather than tabs — a single window with a few hundred tabs does not exhibit the issue.

Expected results:

I expect to be able to open as many windows as I need for my work, and I expect to not be penalized for trying to have some structure around my tabs.

---

My work involves, among other things, coordinating and/on participating in development of some features in my employer’s product. At any given moment, I may have like 3 to 10 features I’m tracking.

Each feature generates a number of tabs. The feature vision, the development roadmap, design mock-ups, bug tracker issues for each unit of work, code reviews, CI builds, development documentation, etc. Enough that I want to keep each feature separate from others.

Sometimes it is convenient to have more than one window per feature. In the planning phase, I may want to be reading the vision and editing the architecture document; I will then want to open them in separate windows so I can see both on my monitor. In active development, I may open a new window for each ticket so that it’s grouped with its code review and relevant docs.

What I’m trying to say here, in my opinion, 318 tabs in 45 windows is not an outrageous session to keep around.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jamie Nicol [:jnicol]]

Thanks for the bug report. I couldn't reproduce on my linux workstation with an AMD GPU.

This error is occurring because eglCreateWindowSurface is returning EGL_BAD_ALLOC. If we're unable to create an EGL surface then we cannot render using hardware acceleration, so must fallback to software.

Perhaps the system is low on memory and the driver is unable to create the window surface. What is the memory usage like when this occurs? Or does it perhaps always occur when creating the 25th window, and perhaps the driver has a built-in limit?

I wonder if using GLX rather than EGL makes a difference? Could you try setting gfx.x11-egl.force-enabled to true in about:config? (needs a restart to take effect)

Comment 3

[Yuri Khan]

Hm, you got me thinking. What kind of memory are we talking? garden variety virtual memory, which can practically made unlimited? physical RAM? rare scarce dedicated video card memory?

My machine has a GeForce RTX 3060 with 6G memory. It’s driving a 5K external monitor. So a full screen is about 15 megapixels. Assuming 32bpp, no compression, that’s roughly 60MB per fullscreen surface. My typical window is one half of a full screen, but the compositor might want to do double buffering, so… I should be able to afford ~100 windows, supposing that all surfaces absolutely need to be resident all the time?

I ran watch -d nvidia-smi. Pressing Ctrl+N in Firefox once increases the GPU memory usage by 100MB by firefox and roughly 30MB Xorg. If I spawn many windows slowly and memory usage rises above some threshold, it eventually shrinks. So no, it looks like they don’t need to be always resident.

However, if I spawn windows rapidly, then eventually Firefox encounters an allocation failure and falls back to software.

But this is exactly what session restore does — It creates a few dozen windows in a short interval of time.

I wonder if using GLX rather than EGL makes a difference? Could you try setting gfx.x11-egl.force-enabled to true in about:config?

I’m assuming you meant gfx.x11-egl.force-disabled.

Did that, and the issue does not seem to reproduce there. I could rapidly create a lot of Firefox windows but about:support did not indicate any fallback to software. The fans did switch to takeoff mode though. Performance on vsynctester.com seems to suffer with GLX.

Comment 4

[Jamie Nicol [:jnicol]]

So spawning windows slowly allows you to create a larger total number before you encounter the error, because some memory is freed during the process? Is there a constant threshold at which the error occurs?

How does the memory usage compare when using GLX, which does not reproduce the issue? Do you eventually encounter this error or some other issue?

Comment 5

[Yuri Khan]

(In reply to Jamie Nicol [:jnicol] from comment #4)

So spawning windows slowly allows you to create a larger total number before you encounter the error, because some memory is freed during the process? Is there a constant threshold at which the error occurs?

How does the memory usage compare when using GLX, which does not reproduce the issue? Do you eventually encounter this error or some other issue?

I have conducted an experiment.

Environment: Ubuntu 24.04, kernel 6.8.0-48-generic as packaged by distro, nvidia-driver-535 and related packages version 535.183.01, i3-wm 4.23, and picom 10.2 running with the xrender backend. Firefox 132 from ppa:mozillateam/ppa, after a clean reboot so no applications are running (except the window manager, compositor, terminal, and Firefox).

In the terminal, I’m running watch -d nvidia-smi and taking notes on GPU memory usage by processes firefox and Xorg. (The notes are on paper, so as not to disrupt the experiment.)

First run: I start firefox -ProfileManager from the terminal, create a clean profile and start spawning windows, one by one, waiting for the memory usage numbers to stabilize.

I see firefox memory usage climb ~100MB, and Xorg 168MB, on each additional window.

With 15 windows, Firefox uses 1634MB and Xorg 4023MB. With the next Ctrl+N, firefox drops to 113MB and Xorg to 3826MB and I see the 0x3003 EGL error in the terminal. I close all windows one by one and terminate the Firefox process that for some reason does not exit on its own after closing the last window.

Second run: I start firefox -ProfileManager from the terminal again, with the same profile. I repeat the process even more slowly.

I see similar numbers, but this time around the 15th window Xorg decides to free 1624MB GPU memory. At 20 windows, it dumps 336MB more. At 21, Firefox frees half its GPU memory.

I reach 28 windows, 1761MB firefox, 3628MB Xorg. The 29th window takes it over the limit, dropping firefox to 113 with the 0x3003 EGL error message. I again close all windows and terminate Firefox.

Third run: I start firefox -ProfileManager from the terminal, create a clean profile, set gfx.x11-egl.force-disabled to true, and restart Firefox with this profile. Again, I start creating windows slowly.

Again, firefox GPU memory usage climbs by ~100MB with each new window; but this time Xorg climbs by 284MB. At 13 windows, Xorg frees up 720MB. At 14, Firefox frees 492MB. At 15, Xorg frees 104. At 16, something happens and Firefox drops its GPU memory usage to 181. No error message, but performance on vsynctester.com is degraded. I close all windows and terminate Firefox.

Fourth run: I start firefox -ProfileManager and choose the same profile as in third run (the one with GLX). I open vsynctester.com and verify that performance matches expectations — the VSYNC label on the right appears gray and the frame timings are consistent. I press Alt+← to go back to the start page so that vsynctester no longer affects the experiment.

I start opening new windows again. Again, GPU memory usage climbs by ~100MB firefox and 284MB Xorg. After 5 windows, I open vsynctester again. Things look good so far.

At 7 windows, firefox GPU memory usage drops from 1810MB to 1278MB (532MB freed). At 9, firefox uses 1505MB and Xorg 3648MB. At 10, it drops to 166MB + 3242MB. I test with vsynctester and it looks like performance has worsened but still halfway acceptable: the VSYNC label has visible tearing with lower part looking gray and upper part cyan. At 13 windows, memory usage goes down again and this time vsynctester has the VSYNC label flashing red and cyan (sign of dropped frames) and frame timings are all over the place.

In this experiment, each new window was full desktop size, i.e 5120×2760 physical pixels. (120 pixels taken by window manager bars.)

I do not know when and why GPU memory usage by a process goes down, or how to force that.