GTX 1060, driver 495.29.05, Gnome X11, Ubuntu 21.10, 2560x1440@60 Hz

STR: Open two windows of vsynctester
$ pip3 install --user mozregression
$ MOZ_X11_EGL=1 mozregression --good 2021-08-01 --bad 2021-10-16 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

17:14.25 INFO: Last good revision: a445650b18589a643e3a4ea08c052493374aa1dd
17:14.25 INFO: First bad revision: 3b0d7e251b85810423c682d1b95ff06f2ceda2e2
17:14.25 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a445650b18589a643e3a4ea08c052493374aa1dd&tochange=3b0d7e251b85810423c682d1b95ff06f2ceda2e2

3b0d7e251b85810423c682d1b95ff06f2ceda2e2 Robert Mader — Bug 1714483 - Force-disable Nvidia FXAA, r=aosmond

2x 60 fps:
MOZ_X11_EGL=1 mozregression --launch 2021-08-01 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

same build with __GL_ALLOW_FXAA_USAGE=0 env var: 2x 36-40 fps
__GL_ALLOW_FXAA_USAGE=0 MOZ_X11_EGL=1 mozregression --launch 2021-08-01 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

Still better than GLX which had and has 2x 30 fps.
mozregression --launch 2021-08-01 --pref gfx.x11-egl.force-disabled:true gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support
mozregression --launch 2021-10-17 --pref gfx.x11-egl.force-disabled:true gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

Err - this is surprising, to say the least. This is all with global FXAA disabled, correct? I.e. there shouldn't be any difference with that bug landed. Apart from the Nvidia driver doing something weird.

Yes, default driver settings, yes it seems like a driver bug.
The bug is also reproducible with a build before the patch (2021-08-01) when manually setting the __GL_ALLOW_FXAA_USAGE=0 env var.

The bug can be fixed by enabling "Force Composition Pipeline" or "Force Full Composition Pipeline" in Nvidia X Server Settings > X Server Display Configuration > Advanced.

Erik, Arthur, it looks like we found an odd driver bug here: setting __GL_ALLOW_FXAA_USAGE=0 appears to have a negative impact on multi-window rendering while it most likely should be a noop - FXAA was already disabled / not manually enadled.

Is that in any way expected / a know issue?

No, this is not expected, and deserves investigation on our end.
https://hg.mozilla.org/integration/autoland/rev/3b0d7e251b85810423c682d1b95ff06f2ceda2e2 looks correct to me in spirit, although the comment isn't so true: this isn't necessarily a driver bug, it just so happens that FXAA is likely not compatible with the type of rendering that Firefox is doing. It's not like 2D text apps will benefit from FXAA anyway, so our take was to disable it in the driver through an application profile, doing substantially the same thing as that change.
It shows up in /usr/share/nvidia/nvidia-application-profiles* as:
{ "pattern": "firefox", "profile" : "FA0" },

and was added following Mozilla bug 1714483

Staying in needinfo as I need to get back to you on what's going on exactly.

(In reply to Darkspirit from comment #0)

same build with __GL_ALLOW_FXAA_USAGE=0 env var: 2x 36-40 fps
__GL_ALLOW_FXAA_USAGE=0 MOZ_X11_EGL=1 mozregression --launch 2021-08-01 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

Is that so? You claim the regression was on 2021-09-17, yet your commandline is for a 2021-08-01 build. Is this a typo or did I misunderstand how to observe the problem?

I tried
_GL_ALLOW_FXAA_USAGE=0 MOZ_X11_EGL=1 mozregression --launch 2021-10-17 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

and did not reproduce the problem

(In reply to Arthur Huillet from comment #7)

Is that so? You claim the regression was on 2021-09-17, yet your commandline is for a 2021-08-01 build. Is this a typo or did I misunderstand how to observe the problem?

He knew that the problem did not reproduce for him with the 2021-08-01 build, but did for the 2021-10-16 one. That way his was able to find the regression.
To double check that nothing else was also at play, he then ran a known good version (anything before Bug 1714483, e.g. 2021-08-01) with the env variable to confirm that setting it causes the issue there as well. So all versions going back to 2021-08-01 reproduce the issue for him when __GL_ALLOW_FXAA_USAGE=0 is set.

I tried
_GL_ALLOW_FXAA_USAGE=0 MOZ_X11_EGL=1 mozregression --launch 2021-10-17 --pref gfx.webrender.all:true -a https://www.vsynctester.com/ -a https://www.vsynctester.com/ -a about:support

and did not reproduce the problem

1. small typo: __GL_ALLOW_FXAA_USAGE (__ instead _ at the start)
2. this build should reproduce the issue, independently of whether you set the env var or not, as it includes bug 1714483 and thus always sets that env. I suppose the issue does not reproduce on your system then?

For the record: another user confirmed that reverting bug 1714483 improves things for them in bug 1640779 comment 71

(Darkspirit from comment #1)

Still better than GLX which had and has 2x 30 fps.

There's a known workaround for the GLX issue (setting layout.frame_rate from -1 to 0 during the session) and no known workaround for this EGL issue.

My mistake, not "this EGL issue". I mean for the other EGL issues.

(In reply to lexlexlex from comment #10)

There's a known workaround for the GLX issue (setting layout.frame_rate from -1 to 0 during the session) and no known workaround for this EGL issue.

Mozilla devs likely wouldn't change legacy GLX.

This bug has a workaround:

(Darkspirit from comment #4)

The bug can be fixed by enabling "Force Composition Pipeline" or "Force Full Composition Pipeline" in Nvidia X Server Settings > X Server Display Configuration > Advanced.

EGL/X11/Nvidia (even without the workaround) is better than the GLX default, with the workaround it performs the same as MOZ_ENABLE_WAYLAND, and it supports swap_buffers_with_damage.
It's not perfect, but good. The remaining problem could be slow MakeCurrent on proprietary Nvidia. (I'm not a developer.)

With the 2021-08-01 build and MOZ_X11_EGL=1 I see https://vsynctester.com report 60FPS, but this is on a 120Hz display. Is this expected? This occurs regardless of the value of __GL_ALLOW_FXAA_USAGE or whether ForceFullCompositionPipeline is enabled. I've also removed the driver application profile Arthur mentioned so that shouldn't be interfering.

Using GLX it reports 120FPS and eglgears_x11 also runs as 120FPS.

(In reply to Erik Kurzinger from comment #13)

With the 2021-08-01 build and MOZ_X11_EGL=1 I see https://vsynctester.com report 60FPS, but this is on a 120Hz display. Is this expected? This occurs regardless of the value of __GL_ALLOW_FXAA_USAGE or whether ForceFullCompositionPipeline is enabled. I've also removed the driver application profile Arthur mentioned so that shouldn't be interfering.

Using GLX it reports 120FPS and eglgears_x11 also runs as 120FPS.

Sorry for the late reply. This should have been fixed by bug 1640779, i.e. in build 2021-10-23.

(In reply to Erik Kurzinger from comment #13)
Please use https://nightly.mozilla.org to reproduce this bug on Gnome X11.

Firefox (Gecko engine) needs to set Nvidia env var __GL_ALLOW_FXAA_USAGE=0 because some people enabled FXAA and suddenly had broken rendering when Firefox (Gecko engine) enabled hardware rendering.
But setting that env var causes a performance regression in the driver.
Workaround: Enabling "Force composition pipeline" basically reverts the performance regression.
Without the workaround, fps is almost as bad as with GLX (bug 1716049 comment 72).

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Since this can provoke issues with getenv() (setting env vars in multithreaded programs is not safe), can this env var setting be done on entry to Firefox before we spawn threads? either in each process separately, or in the main process before it starts spawning threads.

Jan, do you think we could just remove that workaround again? Did recent versions of the Nvidia driver get any better here?

Gnome X11, Ubuntu 22.04.2 LTS, Nvidia GTX1060:
Manually enabled FXAA in Nvidia Settings > X Screen 0 > Antialiasing Settings.

bug 1714483 meant:
GLX=almost white window.
EGL=blurry text.

Old builds from before bug 1714483 comment 35 still behave the same:

• GLX white window: MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --launch 2021-09-01
• EGL blurry text: MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --launch 2021-09-16
• GLX white window: old 78.14.0esr https://archive.torproject.org/tor-package-archive/torbrowser/10.5.6/tor-browser-linux64-10.5.6_en-US.tar.xz with gfx.webrender.all=true

Today:

• Chromium is unaffected.
• __GL_ALLOW_FXAA_USAGE=0 is hardcoded in Gecko
• There are 3 firefox rules in /usr/share/nvidia/nvidia-application-profiles-530.41.03-rc, but none for thunderbird, tor-browser, other firefox forks.

Weighting of interests:
getenv startup crash(bug 1794309 "Nvidia/Linux: Crash in [@ getenv]"/bug 1784813)&possible security problems
vs.
self-inflicted glitch.

(Darkspirit from bug 1794309 comment #4)

I'm not really a programmer, but I assume this could be related to bug 1784813 and it could be worth a try

• to remove this code:
  https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/gfx/thebes/gfxPlatformGtk.cpp#129-132

  // Bug 1714483: Force disable FXAA Antialiasing on NV drivers. This is a
  // temporary workaround for a driver bug.
  PR_SetEnv("__GL_ALLOW_FXAA_USAGE=0");

  • This code is to prevent massive glitches caused by manually enabling FXAA in Nvidia settings. It's the user's own fault.
  • bug 1714483 comment 37: Nvidia has added a blocklist rule for Firefox in their driver, so that users can't manually enable it, but it likely wouldn't apply to Thunderbird, etc.

• at least to restrict this to isMesa:
  https://searchfox.org/mozilla-central/rev/a4a41aafa80bf38f6e456238a60781fed46f9d08/gfx/thebes/gfxPlatformGtk.cpp#174-177

  if (feature.IsEnabled() && IsX11Display()) {
  // Enabling glthread crashes on X11/EGL, see bug 1670545
  PR_SetEnv("mesa_glthread=false");
  }

  • This code is to prevent a crash caused by manually setting mesa_glthread=true environment variable. It's the user's own fault.

Thanks to the EGL/Nvidia rollout and moving older drivers to SW WR, affected users only get blurry text.
Can you add an isMesa check to mesa_glthread=false and remove __GL_ALLOW_FXAA_USAGE=0?

gedit /usr/share/nvidia/nvidia-application-profiles-530.41.03-rc

(Corrected comment: This was tested on Ubuntu 22.04.2 LTS, not 23.04.)