Terrible performance regression with Nvidia 390.25 driver

loqs · 2018-03-12 20:15:41

@bearoso was the 390.42 supposed to?

Fixed a regression, introduced in 390.12, that caused occasional flicker when using the X driver's composition pipeline, for example when using screen transformations like rotation, or the "ForceCompositionPipeline" or "ForceFullCompositionPipeline" options."

bearoso · 2018-03-12 20:35:42

loqs wrote:

@bearoso was the 390.42 supposed to?

Don't know if that's what they were aiming at or not. In the thread at the nvidia forums they seem confused that it's some sort of composition pipeline problem, so it's no leap that they think this is fixing it all. You can't mention anything peripheral to the main problem to the official developers or they'll use it as a scapegoat. Now that this driver is out, it'll be at least another month before we hear anything.

loqs · 2018-03-12 20:47:42

Another month would most likely be after 4.16 is released which currently needs a nasty workaround patch and 390.42 did not include 4.15 modesetting support either so that would be two sets of kernel changes nvidia would have missed.

Batou · 2018-03-13 01:53:07

bearoso wrote:

Before anyone asks, I tried the new 390.42 drivers and they don't fix the performance (Chromium or otherwise).

Well, that's a shame. I did notice that Nvidia guys are reading their own forums and a guy there has responded and they seem to be trying to fix it. I'm still stuck with 387. drivers but they seem to have some serious security issues:

Package nvidia is affected by CVE-2017-5754, CVE-2017-5753, CVE-2017-5715. High risk!. Update to 390.25-1!

rob-tech · 2018-03-13 01:59:48

I think 390.42 is meant to work around the artifacting with composition pipeline issue as it only contains 1 item in the changelog. Hopefully they release more extensive fixes for the performance issues soon as Xorg 1.20 and Linux 4.16 will release soon, and new drivers will be required.

It's unfortunate, but performance is so bad that the Arch installation lies dormant and was only booted twice in about a month to install updates and check for the resolution of this issue. I use Windows 10 currently.

Batou · 2018-03-13 03:46:38

rob-tech wrote:

It's unfortunate, but performance is so bad that the Arch installation lies dormant and was only booted twice in about a month to install updates and check for the resolution of this issue. I use Windows 10 currently.

Just downgrade to 4.14 + 387 or recompile 4.15 to use 387. There's no need to run that horrible OS.

bearoso · 2018-03-13 18:03:46

Batou wrote:

Just downgrade to 4.14 + 387 or recompile 4.15 to use 387. There's no need to run that horrible OS.

I simply made some new packages around the Vulkan release 387.42.05. Works fine and has 4.15 support.

As rob-tech says, they’ll need a new version for the 1.20 ABI, and they likely won’t release new drivers until that is finalized.

Ropid · 2018-03-14 14:52:14

I wrote down detailed instructions of how to make 387.34 work with the current 4.15 kernel packages. I posted it here:

https://bbs.archlinux.org/viewtopic.php … 6#p1773906

It has download links for all the old 387.34 nvidia-utils etc. packages, a download link for that patch that @loqs shared a few pages ago somewhere in this thread, and a download link to a tweaked PKGBUILD that applies that patch and builds just the "nvidia-dkms" package (no "nvidia" package) to make it work with any kernel.

Pillgar · 2018-03-14 23:40:55

Is anyone at all able to get into their desktop, with "ForceCompositionPipeline" or "ForceFullCompositionPipeline" enabled in xorg, on boot up? I'm still seeing the black screen with the mouse cursor when these options are enabled in any 390 version... and it's been well over a month now.

afader · 2018-03-15 00:14:43

I have upgraded to 390.42 and everything works fine. My gnome session runs under Xorg, not wayland. My grub.cfg:

linux /boot/vmlinuz-linux-zen root=UUID=edb18a03-4a5c-44e1-8405-6d0846a4849c rw cgroup_enable=memory swapaccount=1 scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y nvidia-drm.modeset=1 PCI=biosirq

My xorg.conf:

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "DVI-D-0: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-I-1: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
Option "TripleBuffer" "True"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Kabir · 2018-03-15 01:28:31

Upgraded to nvidia 390.42. Chromium works smoothly now. Also the "suspend swap group failed / resume swap group failed" warnings have not appeared so far after resuming from suspend, however Chromium still crashes after waking from suspend, and the process (chromium) has to be killed and restarted to get Chromium to work after suspend.

Pillgar · 2018-03-15 02:48:21

afader wrote:

I have upgraded to 390.42 and everything works fine. My gnome session runs under Xorg, not wayland. My grub.cfg:
linux /boot/vmlinuz-linux-zen root=UUID=edb18a03-4a5c-44e1-8405-6d0846a4849c rw cgroup_enable=memory swapaccount=1 scsi_mod.use_blk_mq=y dm_mod.use_blk_mq=y nvidia-drm.modeset=1 PCI=biosirq
My xorg.conf:
Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "Stereo" "0"
Option "nvidiaXineramaInfoOrder" "DFP-0"
Option "metamodes" "DVI-D-0: nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DVI-I-1: nvidia-auto-select +1920+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"
Option "SLI" "Off"
Option "MultiGPU" "Off"
Option "BaseMosaic" "off"
Option "TripleBuffer" "True"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Our xorg files are almost identical besides resolutions. I take it you're using GDM to login?

Update. NVM regarding the display manager. I narrowed it down to the displays.xml file for XFCE. When ever the position for the secondary monitor in displays.xml, was set to the same x and y value in xorg.conf, the black screen would appear upon boot with {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On} in xorg. Though it doesn't happen with compositing disabled, or when non-matching x and y values are used with it enabled.

Last edited by Pillgar (2018-03-15 06:22:09)

wh00 · 2018-03-15 15:06:11

Kabir wrote:

Upgraded to nvidia 390.42. Chromium works smoothly now.

Same here

Batou · 2018-03-15 16:19:18

Pillgar wrote:

Is anyone at all able to get into their desktop, with "ForceCompositionPipeline" or "ForceFullCompositionPipeline" enabled in xorg, on boot up? I'm still seeing the black screen with the mouse cursor when these options are enabled in any 390 version... and it's been well over a month now.

Try completely removing your xorg.conf file (rename it to something else). Composition Pipeline is the known culprit with new drivers and Xorg doesn't seem to work with it.

Anyway, Nvidia apparently knows what's going on and will fix it at some point:

aplattner wrote:

Thanks for confirming. We've identified which part of the driver is being affected by the Chrome sandbox and are looking into ways of working around it. For future reference, the internal bug number tracking that effort is 2076012.
https://devtalk.nvidia.com/default/topi … =110#reply

390.42 changelog just fixes some of the flickering. 390.xx will have issues until the root issue is resolved (maybe next month?).

Ropid · 2018-03-15 17:01:08

wh00 wrote:

Kabir wrote:
Upgraded to nvidia 390.42. Chromium works smoothly now.
Same here

This seems is not the case for me. I test like this (someone on the nvidia forums mentioned this):

(1) Press Ctrl-Shift-i to open the developer tools thingy in the lower half of the screen.
(2) On the left side, choose the "elements" tab that shows the HTML code of the page you are currently viewing,
(3) then on the right side go to the "styles" tab and look for any entry that's about a color.
(4) On any entry about a color, click on the color square to open the color picker tool.

Now in the color picker tool, if I hold down the left mouse button in the rectangular top area to select some shade, moving the selection around will lag terribly with 390.42 drivers. It's like it updates at 10fps or something. In comparison, this is completely fine in 387.34 where it looks like it updates at 60fps.

Last edited by Ropid (2018-03-15 17:02:28)

Batou · 2018-03-15 17:12:00

Ropid wrote:

wh00 wrote:
Kabir wrote:
Upgraded to nvidia 390.42. Chromium works smoothly now.
Same here
This seems is not the case for me. I test like this (someone on the nvidia forums mentioned this):
(1) Press Ctrl-Shift-i to open the developer tools thingy in the lower half of the screen.
(2) On the left side, choose the "elements" tab that shows the HTML code of the page you are currently viewing,
(3) then on the right side go to the "styles" tab and look for any entry that's about a color.
(4) On any entry about a color, click on the color square to open the color picker tool.
Now in the color picker tool, if I hold down the left mouse button in the rectangular top area to select some shade, moving the selection around will lag terribly with 390.42 drivers. It's like it updates at 10fps or something. In comparison, this is completely fine in 387.34 where it looks like it updates at 60fps.

Yeah, that's an easy way to confirm that it doesn't work well at all. 390.42 came out before Nvidia even identified what was wrong (just going off public postings and the 42's changleog). It doesn't fix the root cause of horrible performance in games/chromium at all. We'll have to wait for the next release (if it ends up including fixes for this).

wh00 · 2018-03-15 17:44:34

Pillgar wrote:

Is anyone at all able to get into their desktop, with "ForceCompositionPipeline" or "ForceFullCompositionPipeline" enabled in xorg, on boot up? I'm still seeing the black screen with the mouse cursor when these options are enabled in any 390 version... and it's been well over a month now.

This has been happening to me, as well. I just switch to another TTY and then back, and sddm starts normally.

wh00 · 2018-03-15 17:46:29

Ropid wrote:

wh00 wrote:
Kabir wrote:
Upgraded to nvidia 390.42. Chromium works smoothly now.
Same here
This seems is not the case for me. I test like this (someone on the nvidia forums mentioned this):
(1) Press Ctrl-Shift-i to open the developer tools thingy in the lower half of the screen.
(2) On the left side, choose the "elements" tab that shows the HTML code of the page you are currently viewing,
(3) then on the right side go to the "styles" tab and look for any entry that's about a color.
(4) On any entry about a color, click on the color square to open the color picker tool.
Now in the color picker tool, if I hold down the left mouse button in the rectangular top area to select some shade, moving the selection around will lag terribly with 390.42 drivers. It's like it updates at 10fps or something. In comparison, this is completely fine in 387.34 where it looks like it updates at 60fps.

You are right. I can reproduce this behavior. I just don't get the flashing from previous 390.x drivers.

pvn · 2018-03-15 18:27:21

I see an improvement in 390.42 compared to 390.25. But it is still worse than 387.34. I have not seen any flickering and artifacts so far but the performance in Chromium is lacking. By the way the following option as suggested here made things worse. Especially in the color picker test in chromium. I have Quadro P2000.

Option "UseNvKmsCompositionPipeline" "false"

Pillgar · 2018-03-16 00:11:40

I did manage to get things sorted out regarding xorg with CompositionPipeline enabled on boot by deleting the secondary display position values in the displays.xml file for xfce (deleting that file also works). Creating a new xorg.conf was no success nor was switching between tty's. It seems somewhat counter-intuitive that having the same display position value's in both displays.xml and xorg would cause this bug, but I'm happy to finally have it sorted. TY for the suggestions.

ulteq · 2018-03-16 16:13:29

Option "UseNvKmsCompositionPipeline" "false"

This at least solved for me both the high idle power consumption, as well as the screen tearing in Firefox.

Enverex · 2018-03-16 16:17:50

That driver entry suggested by aplattner on the official forum worked for me too. Temps, load and such are all back to normal on the new driver now.

kokoko3k · 2018-03-16 21:31:02

I wonder why it is an undocumented option.

Ropid · 2018-03-16 22:18:34

I tried using that xorg.conf entry and 390.42 just now, and that Chrome color-picker still was laggy with it, so that part of the problem isn't solved at all for me.

l0k1verloren · 2018-03-21 12:33:55

I have worse issues with the new versions. Since, I'm not sure exactly when, sometime in february probably, my X session has been randomly crashing especially when running electron apps. I dialed back all my packages to december 31 and the problem has gone, and my nvidia version is 387. I am sure the problem is either linux or nvidia, or both.

Arch Linux

#176 2018-03-12 20:15:41

Re: Terrible performance regression with Nvidia 390.25 driver

#177 2018-03-12 20:35:42

Re: Terrible performance regression with Nvidia 390.25 driver

#178 2018-03-12 20:47:42

Re: Terrible performance regression with Nvidia 390.25 driver

#179 2018-03-13 01:53:07

Re: Terrible performance regression with Nvidia 390.25 driver

#180 2018-03-13 01:59:48

Re: Terrible performance regression with Nvidia 390.25 driver

#181 2018-03-13 03:46:38

Re: Terrible performance regression with Nvidia 390.25 driver

#182 2018-03-13 18:03:46

Re: Terrible performance regression with Nvidia 390.25 driver

#183 2018-03-14 14:52:14

Re: Terrible performance regression with Nvidia 390.25 driver

#184 2018-03-14 23:40:55

Re: Terrible performance regression with Nvidia 390.25 driver

#185 2018-03-15 00:14:43

Re: Terrible performance regression with Nvidia 390.25 driver

#186 2018-03-15 01:28:31

Re: Terrible performance regression with Nvidia 390.25 driver

#187 2018-03-15 02:48:21

Re: Terrible performance regression with Nvidia 390.25 driver

#188 2018-03-15 15:06:11

Re: Terrible performance regression with Nvidia 390.25 driver

#189 2018-03-15 16:19:18

Re: Terrible performance regression with Nvidia 390.25 driver

#190 2018-03-15 17:01:08

Re: Terrible performance regression with Nvidia 390.25 driver

#191 2018-03-15 17:12:00

Re: Terrible performance regression with Nvidia 390.25 driver

#192 2018-03-15 17:44:34

Re: Terrible performance regression with Nvidia 390.25 driver

#193 2018-03-15 17:46:29

Re: Terrible performance regression with Nvidia 390.25 driver

#194 2018-03-15 18:27:21

Re: Terrible performance regression with Nvidia 390.25 driver

#195 2018-03-16 00:11:40

Re: Terrible performance regression with Nvidia 390.25 driver

#196 2018-03-16 16:13:29

Re: Terrible performance regression with Nvidia 390.25 driver

#197 2018-03-16 16:17:50

Re: Terrible performance regression with Nvidia 390.25 driver

#198 2018-03-16 21:31:02

Re: Terrible performance regression with Nvidia 390.25 driver

#199 2018-03-16 22:18:34

Re: Terrible performance regression with Nvidia 390.25 driver

#200 2018-03-21 12:33:55

Re: Terrible performance regression with Nvidia 390.25 driver

Board footer