440.36 with Bumblebee drops to ~1 FPS after running for 10 minutes

Graphics / Linux Linux
1

After upgrading to my Nvidia driver to 440.36, I (and several others on the Archlinux forums and Redit) have run into a problem where the frame rate drops to ~1 FPS after 10 minutes of loading the driver and bringing the card up with Bumblebee (to control Optimus). This timing is reliable, regardless of load. It occurs for me whether running Kerbal Space Program, Glxspheres64 or Gedit. It is not a thermal problem (it happen even with no real load).

If I quit the program (which causes bumblebee to unload the driver and power down the card), I can then re-start with bumblee and get another solid 10 minutes of performance before it drops to 1 FPS again.

Some specifics:
Archlinux, up-to-date system
GTX-1050ti Max-Q (I’m running a Thinkpad X1E)
Running via both the “primusrun” and “optirun” command, using Bubmblee
Happens only with the 440.36 driver. If I roll back to 435.21 or 390.132, the problem goes away.

I can’t find anything useful in the logs, I’ll pull some together and post (the catch is since I’m using bumblebee, the regular log-dump tool doesn’t give any Xorg outputs) when I get a chance, but I figured I’d start the thread here for others who are seeing the same problem.

One curious part, which I’m hoping is telling, is the fact that it always times out at 10 minute.s

2

I have a TurboVNC+VirtualGL system that also degrades to quite exactly 1 FPS after some time with the 440 series.

After reverting to 430 everything is fine again.

Both Bumblebee/Primus and VirtualGL need fast reads from GPU memory …

1 FPS and 10 min …

Someone must have had a very brilliant idea.

3

Isn’t there an already known/reported memory leak with the 440 driver? Maybe same bug?

4

No idea. I don’t see any problems with 440.36 on my desktop (without optimus).

5

I suspect this is caused by the HardDPMS option, which is enabled by default now. When active, this limits the frame rate to 1 fps when DPMS kicks in because otherwise, applications would start rendering as fast as possible.

However, that limit shouldn’t be applied for displayless setups like Bumblebee. I filed internal bug 2775447 to track fixing that.

In the meantime, you should be able to work around the problem by disabling DPMS in the Bumblebee X session, either by disabling the HardDPMS option in xorg.conf or by running “xset s off -dpms” in the sessions setup.

1 Like
6

I just ran a test with:

Option "HardDPMS" "false"

in the screen section of /etc/bumblebee/xorg.conf.nvidia and that looks like it’s cleared up the issue. I’m at about 14 minutes now without the drop in frame rate.

Thanks for the help!

7

What about not enabling HardDPMS by default for Teslas or if the user has set “UseDisplayDevice” “None”?

8

This had fixed this issue for me, thank you.

I don’t have a Screen section in my /etc/bumblebee/xorg.conf.nvidia file, so I added the above HardDPMS false setting to the Device section and it seems to have worked just the same.