1389491 - Stop using glXWaitVideoSyncSGI

Status: RESOLVED DUPLICATE of bug 1640779

(Core :: Graphics, defect, P3)

Description

[Dzmitry Malyshau [:kvark]]

New NVidia driver 378.13 causes a regression on Firefox because of the bug in `glXWaitVideoSyncSGI` implementation. We are advised to stop using this extension. See NV dev forum:

https://devtalk.nvidia.com/default/topic/1001899/linux/nvidia-378-13-cause-100-load-one-cpu-core-when-running-firefox-hwaccel-opengl-/post/5118566/#5118566

Comment 1

[Dzmitry Malyshau [:kvark]]

Used here:

http://searchfox.org/mozilla-central/rev/4b79f3b23aebb4080ea85e94351fd4046116a957/gfx/thebes/gfxPlatformGtk.cpp#753

Comment 2

[Dzmitry Malyshau [:kvark]]

NVidia will have a workaround in the driver so that end users are not affected, thus I'm lowering the priority here.
This is still something we need to do.

Comment 3

[Alexander Bus]

Attachment: Firefox 2020-01-30 19.50 profile.json.gz

I just encountered an issue that's related to glXWaitVideoSyncSGI.
Turning off the screen via DPMS causes GLXVsyncThread of Firefox to spin the CPU at 100% until the screen turns back on.
Happens on current nightly and on versions as far back as 69 (mozregression reported this first bad revision: b19ffb3ca153242cc668db6549940b421f176d4b). Requires layers.acceleration.force-enabled: true or having WebRender enabled.
The version of Nvidia drivers is 440.44 (Linux 64-bit) and my GPU is GTX 660. I can't easily try older versions of Nvidia drivers, so all I can say is that the issue started happening recently, maybe a month or two ago (perhaps when 440.44 shipped in the beginning of December).
I'm attaching a report from the profile.

Comment 4

[Ivan]

The issue is still persist with nvidia-drivers-455.28 and firefox-82.0.2 along with layers.acceleration.force-enabled=true and webgl.force-enabled=true

Comment 5

[amrit1711]

Hi Ivan,
I used below two setups and opened around 10 tabs including youtube, facebook, amazon and few other random websites where CPU utilization spiked for fraction of seconds and come back to normal state.

Precision T7600 + Arch Linux + Quadro RTX 8000 + Driver 455.28 + Mozilla Firefox 81.0.2 with config layers.acceleration.force-enabled=true, webgl.force-enabled=true+ ForceCompositionPipeline=ON

Precision T7600 + Arch Linux + Quadro RTX 8000 + Driver 455.38 + Mozilla Firefox 78.0.2 with config layers.acceleration.force-enabled=true, webgl.force-enabled=true+ ForceCompositionPipeline=ON

Can you please share nvidia bug report and specific links which you are using it so that I can have my setup similar to yours.
It would be good to have repro video to understand how long you are seeing 100% utilization on one of the core using htop.

I also disabled forcecompositepipeline and can not recreate issue locally.

Comment 6

[Ivan]

Hi amrit1711 ,
My setup is Gentoo + GeForce GTX 980 + nvidia-drivers-455.38 +kde plasma 5.20.2 + Firefox 82.02 with layers.acceleration.force-enabled=true, webgl.force-enabled=true and without ForceCompositionPipeline.

Firefox cpu utilization with dpms off is not reproducible 100% of cases, usually it happens when firefox is minimized to tray and screen goes off and it come back to normal only when screen activated.

Attaching nvidia-bug-report.log.gz and screenshot of htop

Comment 7

[Ivan]

Attachment: Screenshot_20201104-163718.jpg

Comment 8

[Ivan]

Attachment: nvidia-bug-report.log.gz

Comment 9

[amrit1711]

Hi Ivan,
Thanks for providing repro steps, looks like I observed the same behavior as you mentioned above.

Precision T7600 + Ubuntu 19.10 + 5.3.0-64-generic + Driver 455.38 + TITAN Xp + Mozilla Firefox 78.0.2 +

Steps to Reproduce -

1. Enabled layers.acceleration.force-enabled=true, webgl.force-enabled=true on firefox
2. Opened 4 tabs with youtube, nvidia.com, facebook and amazon webiste
3. Waited for display to sleep
4. Observed CPU utilization as 100%, below is the screenshot for reference.
5. Enabled the desktop and observed CPU utilization back to normal state.
6. Kept the system idle again for a minute and display went into sleep mode and CPU utilization spiked to 100% again.

We will debug this issue now and keep you posted on the same....