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.
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.
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?
Latest Firefox X86_64 with force enabled OpenGL compositing (in about:config layers.acceleration.force-enabled=true, webgl.force-enabled=true).
Open in Firefox 3-5-7 tabs with any links.
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).
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.