nvidia 378.13 cause 100% load one CPU core when running Firefox (hwaccel, OpenGL)

The new 378.13 driver cause constantly 100% load at one of eight core of my CPU when running FIrefox-52 (52.0.1, 52.0.2) with turned on in Firefox hardware acceleration (OpenGL). This load start after i opened 3-5 different urls in different tabs. Even if you open one tab - this causes an excessive peak, but a short-term load on the CPU, which is not observed with another version of the driver (375.39).
There is no problem with 375.39 driver - very small CPU consumption all time. This behavior tested with clean profile of Firefox, with self-compiled Firefox and Firefox-bin from official Mozilla site and from Gentoo portage.
Also Chromium with hw acceleration no cause this problem.

Gentoo X86_64, GeForce 1050, AMD FX-8320E.

Try gentoos bugzilla, as far as NVIDIA is concerned, gentoo is unsupported distro.
Also, I’m not 100% this is related to nvidia driver itself.

I described this bug a month ago at bugs.gentoo.org, but there also could not find the reason - whether it’s a driver, whether it’s Firefox and a bug marked as Resolved WONTFIX.

Does the problem go away if you set __GL_THREADED_OPTIMIZATIONS=0?

Yes. With env __GL_THREADED_OPTIMIZATIONS=0 firefox there is no problem, the behavior is the same like with 375.39 driver.
How can this be explained?
Is this a problem in the driver or in Firefox?

P.S. I understand. From changelog 378.13: Enabled OpenGL threaded optimizations by default in the driver. Refer to the “Threaded Optimizations” section in the “Specifying OpenGL Environment Variable Settings” chapter of the README for details. These optimizations will self-disable when they are degrading performance. As a result, performance should be unchanged for many applications, and increased for those that benefit from threaded optimizations and were not already forcing them enabled.

P.P.S. In the NVIDIA X Server Settings I created the rule with __GL_THREADED_OPTIMIZATIONS=0 for firefox.

P.P.P.S. Why does not these optimizations automatically self-disable when the performance drops, as this described in changelog?

That would be a driver bug that we need to investigate. Can you please provide a complete, yet minimal, recipe to reproduce the problem so we can investigate?

  1. Nvidia driver 378.13.
  2. Latest Firefox X86_64 with force enabled OpenGL compositing (in about:config layers.acceleration.force-enabled=true, webgl.force-enabled=true).
  3. Open in Firefox 3-5-7 tabs with any links.
  4. Start htop and look at CPU load: one of CPU core will be have 100% load. One or two tabs not cause the problem, but when you trying open one tab - this causes an excessive peak, but a short-term 100% load on the multiple cores of the CPU, which is not observed with another version of the driver (375.39).

Another question: do you observe the same problem with r375 drivers if you set __GL_THREADED_OPTIMIZATIONS=1?

Yes, __GL_THREADED_OPTIMIZATIONS=1 with r375 driver cause the same problem.

We are tracking this issue under bug id 1899001

I can confirm that unsetting disabling (=0) threaded optimizations fixes the problem here as well on 378.13.

The current behavior is arguably a bug, but it’s expected behavior when an application uses glXWaitVideoSyncSGI. Firefox should probably not be using that old extension.
In any case, threaded optimizations aren’t going to be helpful with glXWaitVideoSyncSGI (because the application is asking for its OpenGL calling thread to be stalled!).
Note that these optimizations are disabled by default in our upcoming r381 release.


Is this reported upstream (mozilla) bugzilla or should we do it?

This is reported upstream, https://bugzilla.mozilla.org/show_bug.cgi?id=1389491