Terrible performance regression with Nvidia 390.25 driver

Kabir · 2018-02-20 11:36:32

seth wrote:

Does anybody here have the problem and does NOT use the full composition pipeline? (NOTICE that an active multiscreen setup or viewport transformations like scaling the output will implicitly activate it)

I have not used force composition pipeline or force full composition pipeline and problems do exist with the current NV 390, Im running kernel 4.15.3-2. However the problems I experience are not very severe, I dont get any kind of screen tearing or atrifacts. I dont use vsync in compton. Compton only has backend="glx" enabled, besides shadow and fading effects. Videos on mpv and youtube play smoothly. Glxgears shows the fps to be exactly the same as the refresh rate of the monitor.

As far as the problems are concerned:
Chromium was way more fluid to use with NV 387 series, scrolling was butter smooth. I have not changed any hardware acceleration settings in chromium, its the same as it was with NV 387. Other than this, the only problem I face is not being able to resume from suspend or hibernate without the insane amounts of Suspend swap errors filling the logs and chromium crashes after I resume, all other GUIs retain their state, however the warnings continue whether or not I had chromium running before going into suspend. I guess the devs at nvidia are looking into this, but they havnt said so on their forums.

jwhendy · 2018-02-24 04:08:28

@Kabir: I admit to not having read the entire thread, but I searched for my main issue originally without success: "chromium black upon resume from suspend arch." I think you're the first person I've seen mention that combination explicitly. I started opening my lid to a black screen and bizarre behavior. Alt+tab would switch windows but forever leave the black of chromium in the background. I could quit chromium and restart and everything came back to life. You're saying that it's actually a resume error, though, and without ever starting chromium you had issues (or at least errors)?

I'll have to check this. For now I've downgraded to 387.34-21 and 4.14.15. Overall your'e still happy with 390, though?

Last edited by jwhendy (2018-02-24 04:08:55)

Tom B · 2018-02-24 05:40:30

I've found another annoying issue with these drivers, Chromium seems to lag the entire system. If I'm watching a video in VLC and scrolling down a busy-ish page (e.g. facebook) as Chromium stutters, it causes the video to stutter as well.

axel · 2018-02-24 08:12:27

@jwhendy and @Kabir I also can't use chromium upon resume from suspend.

Kabir · 2018-02-24 08:34:26

@jwhendy, @axel: Without using suspend, chromium doesnt have any severe symptoms for me. Scrolling is slightly better in this recent 390 update, there is a slight stutter though, for the first second or so when starting a youtube video. I still get "suspend/resume swap group failed" warnings in the xorg logs after resuming from suspend. These warnings dont seem to be connected to chromium, but maybe its because of the memory allocation bug fix and broken vsync, according to the nvidia devs.

TheChickenMan · 2018-02-26 02:20:44

Guiluge wrote:

Because it's their job, obviously. And they can't test everything, since there are basically Nvidia techs being paid for that purpose.
I agree with you, these drivers are plain bad, but Nvidia is the only one to blame here.
I can manage with these drivers through Opera by disabling hardware accel, but it's a temporary fix.

Temporary fix for sure. I ended up reverting / freezing nvidia and my kernel drivers as the performance decrease was not acceptable (especially in chromium which is my most used application). I was checking back, kind of hoping to see more of this having been worked out by now. It has been some time since this started. At least the kernel / video drivers are relatively self-contained. I would hope though for a working fix of some kind before 4.16 or beyond.

Last edited by TheChickenMan (2018-02-26 02:21:40)

Batou · 2018-02-26 06:15:23

WRT terrible Chromium performance... just downgrade to 4.14 and 387 drivers. Unless you're a service provider and need Spectre 1 mitigation, there's absolutely no need to run 4.15. You gain almost nothing and lose huge amounts in performance. Nvidia totally dropped the ball with 390 and it's by far the worst driver I've ever used in the last 5 years of using various Linux distros. It should have been blacklisted by Arch. This garbage is unfit to be in production. And it's been weeks since it was released and there's been no fixes and no posts/comments of any kind from Nvidia.

Just downgrade and blacklist these """upgrades""".

pvn · 2018-02-28 18:48:05

Batou wrote:

WRT terrible Chromium performance... just downgrade to 4.14 and 387 drivers. Unless you're a service provider and need Spectre 1 mitigation, there's absolutely no need to run 4.15. You gain almost nothing and lose huge amounts in performance. Nvidia totally dropped the ball with 390 and it's by far the worst driver I've ever used in the last 5 years of using various Linux distros. It should have been blacklisted by Arch. This garbage is unfit to be in production. And it's been weeks since it was released and there's been no fixes and no posts/comments of any kind from Nvidia.
Just downgrade and blacklist these """upgrades""".

+1

I reverted to linux 4.14.5-1 with nvidia 387.34-21 and it is rock solid. Nvidia 390.25 makes both my computers absolutely unusable - everything is extremely slow and I see flickering artifacts all the time. I did:
IgnorePkg = linux linux-headers nvidia nvidia-utils virtualbox-host-modules-arch nvidia-settings

Arch Linux is my main OS for the last 10 years and this is the first time I ever use the "IgnorePkg" option. 390.25 should be removed from the repo altogether. We have this problem for a month already.

loqs · 2018-02-28 19:33:11

pvn wrote:

Arch Linux is my main OS for the last 10 years and this is the first time I ever use the "IgnorePkg" option. 390.25 should be removed from the repo altogether. We have this problem for a month already.

If no one files a bug report requesting that and the maintainer and users of the testing repo who signed off on the package are not experiencing the issue why would it be removed?
Apart from removing support for GeForce GTX 1060 5GB and Quadro P620 it is not clear what percentage of users are affected by the issue to justify an epoch revert.
Even if you want to downgrade to 387 patching for 4.15 support is trivial. Nvidia is also missing support for 4.16 so in 5~7 weeks when arch packages 4.16 the nvidia packages could
block the kernel packages leaving staging unless nvidia produces a new release or arch changes the kernel or changes the module licence to GPL.

wh00 · 2018-03-01 16:49:09

For reference, I am also experiencing screen flashing and poor overall performance w/ a GeForce GT 740 (GK107).

Tom B · 2018-03-01 23:18:51

I don't know if this helps, but doing a little testing between kokoko3k's image and my own, there is a consistent stutter triggered by I/O.

In games, when new graphical assets load (e.g. when an enemy with a model that hasn't been loaded yet is about to be rendered) there is a noticeable stutter, system wide.

Here's a quick and easily reproducible test: Play a video in VLC, then open Chromium. The video stutters as chromium loads. (I don't think VLC matters here, but Chromium is a definite culprit. I used VDPAU output in VLC for both tests).

The stutter doesn't happen on kokoko3k's image. The video plays flawlessly. (or the stutter is < 1/24th second so not to interfere with the video)

I don't believe it's a disk I/O issue as I'm running everything from an nvme drive. Just to rule it out, here's a quick benchmark:

hdparm -Tt /dev/nvme0n1

/dev/nvme0n1:
 Timing cached reads:   25852 MB in  2.00 seconds = 12945.46 MB/sec
 Timing buffered disk reads: 8022 MB in  3.00 seconds = 2673.95 MB/sec

edit: Playing the video from a different disk and launching chromium, same issue.

Last edited by Tom B (2018-03-01 23:25:21)

Batou · 2018-03-01 23:38:52

loqs wrote:

Apart from removing support for GeForce GTX 1060 5GB and Quadro P620 it is not clear what percentage of users are affected by the issue to justify an epoch revert.

I have 1070 / 8GB and I'm affected. So, 1060 / 6GB and Quadro P620 are also confirmed? I hope Nvidia is tracking all this but their lack of communication is discouraging.

pkaske · 2018-03-02 13:34:29

I've just chatted with the German Nvidia Support. They were very friendly. I asked them if they could at least provide feedback in the Nvidia Dev Forum on the existing thread about this.
The support person said that he will forward the request.

In case somebody didn't find the thread in the Nvidia Dev Forum: https://devtalk.nvidia.com/default/topi … n-390-25/1

afader · 2018-03-04 03:53:18

Things are much better for me after switching back to Xorg from Wayland.

Ghosthree3 · 2018-03-05 01:29:22

I moved to linux-lts (4.14) and the nvidia-dkms 387.34-9 package then blacklisted it (and the other nvidia packages that I downgraded to the matching version number). This seemed like the easiest solution that allows me to still update the kernel, someone please confirm.

EDIT: I'm actually going to drop back to nvidia-dkms 375.26-6 because of https://devtalk.nvidia.com/default/topi … ia-drivers, to which a dev admitted to a problem introduced in 378 that wouldn't be fixed until 390, which is clearly not an option.
EDIT2: I don't think I can actually do that, there's a conflict with the current version of mesa so it looks like I'll be sticking with 387.34.

Last edited by Ghosthree3 (2018-03-05 08:14:12)

loqs · 2018-03-06 01:46:09

https://devtalk.nvidia.com/default/topi … 2/#5243122

Aaron Plattner wrote:

Sorry for the slow reply. We're looking into the interaction problem with Chrome, but haven't reproduced the problem as described in this thread. I personally use Chrome with the composition pipeline enabled every day and haven't seen this problem.

Those who have been researching the issue might want to supply their research results in that thread or refer that thread to this one.

kokoko3k · 2018-03-06 08:10:35

Guys, i'm unable to reproduce, but you may want to try to spot differences between my live usb image and your installation.
As Tom B pointed out, it has issues on his system, but NOT when booting the live usb image.
https://bbs.archlinux.org/viewtopic.php … 2#p1768202

pvn · 2018-03-08 21:08:29

@kokoko3k

On my system with nvidia 387.34-21 and also with your image with nvidia 390.25 I get this in chrome://gpu:

Video Decode: Software only, hardware acceleration unavailable

Installing nvidia 390.25-15 and rebooting results in:

Video Decode: Unavailable

Any ideas?

Edit 1:
I found the solution: Go to chrome://flags, enable "Override software rendering list" and relaunch chromium. The result:

Video Decode: Hardware accelerated

Edit 2:
Enabling the video decode helped but the performance degradation and artifacts are still there. Also the mouse cursor is not smooth.

Last edited by pvn (2018-03-08 21:33:47)

loqs · 2018-03-08 21:17:12

https://devtalk.nvidia.com/default/topi … 6/#5243986

Aaron Plattner wrote:

For both the slow performance problem and the green rectangle screen recording problem, can you please test starting Chrome with the --no-sandbox option to see if that makes either of these problems go away?

Edit:
disclaimer disabling multiple protection mechanism makes the chromium more vulnerable test at your own risk

Last edited by loqs (2018-03-08 21:19:19)

pvn · 2018-03-08 21:38:09

@loqs, good find! With --no-sandbox chromium works great!

echo "--no-sandbox" >> ~/.config/chromium-flags.conf

The reason people were unable to reproduce the problem with @kokoko3k's image is because in his image chromium does not even start without this option and you must specify it.

Last edited by pvn (2018-03-08 21:51:10)

Ropid · 2018-03-09 05:48:56

I experimented around a bit and got things to work fine for me here with something different, not the "--no-sandbox" option:

I went through what's mentioned in the Chromium ArchWiki article about how to enable all possible hardware acceleration, and things now seem to run great here for me. The section in the Wiki article I'm talking about is "4.2 Force 3D acceleration". My flags config file looks like this:

--enable-native-gpu-memory-buffers

To be concrete about what I did exactly, I followed these instructions here:

[...] to force 3D rendering, enable the flags: "Override software rendering list", "GPU rasterization", "Zero-copy rasterizer" in chrome://flags. Check if it is working in chrome://gpu.

Now checking on the chrome://gpu page, everything in the first section has a green "Hardware accelerated" mentioned, except for "CheckerImaging" saying "Disabled".

kokoko3k · 2018-03-09 09:18:04

pvn wrote:

@loqs, good find! With --no-sandbox chromium works great!
echo "--no-sandbox" >> ~/.config/chromium-flags.conf
The reason people were unable to reproduce the problem with @kokoko3k's image is because in his image chromium does not even start without this option and you must specify it.

...But chromium was not the only browser to expose issues, right?
Also firefox runs smooth on the usb image.

cirrus9 · 2018-03-09 12:45:24

Chromium was the main issue for me. Firefox showed little, if any problems on my system. Chromium was using much more CPU than Firefox, when displaying the same web pages. That does seem to be better after the latest kernel/nvidia updates. I really am not sure what problems others had with all this, but Chromium certainly had the worst problems for me.

vsync has never worked well for me with Chromium, but Firefox has always done better.

Last edited by cirrus9 (2018-03-09 12:47:26)

pvn · 2018-03-09 20:14:57

kokoko3k wrote:

pvn wrote:
@loqs, good find! With --no-sandbox chromium works great!
echo "--no-sandbox" >> ~/.config/chromium-flags.conf
The reason people were unable to reproduce the problem with @kokoko3k's image is because in his image chromium does not even start without this option and you must specify it.
...But chromium was not the only browser to expose issues, right?
Also firefox runs smooth on the usb image.

Chromium was causing most of the problems. Now I still see artifacts every now and then but at least the system is usable. I cannot tell for sure if all artifacts are caused by chromium since chromium is always running. I may try to force myself to use Firefox for a day or two to see how it goes. I still feel that the 390.25 driver makes my system a little sluggish and the GPU temperature is 3-5C higher. I don't play any games.

By the way I removed "--no-sandbox" from ~/.config/chromium-flags.conf just for test and Video Decode remained "Hardware accelerated" after chromium restart. I even restarted the whole computer and I no longer need "--no-sandbox" in order to get hardware acceleration for Video Decode. I have not changed anything else. Go figure.

I added "--enable-native-gpu-memory-buffers" as @Ropid pointed out and this enabled "Native GpuMemoryBuffers". Thank you Ropid. After a quick research I also added "--enable-features="CheckerImaging" which enabled CheckerImaging. Now everything is green in chrome://gpu.

$ cat ~/.config/chromium-flags.conf 
--enable-native-gpu-memory-buffers
--enable-features="CheckerImaging"
$

Last edited by pvn (2018-03-09 20:17:03)

bearoso · 2018-03-12 20:02:02

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

Arch Linux

#151 2018-02-20 11:36:32

Re: Terrible performance regression with Nvidia 390.25 driver

#152 2018-02-24 04:08:28

Re: Terrible performance regression with Nvidia 390.25 driver

#153 2018-02-24 05:40:30

Re: Terrible performance regression with Nvidia 390.25 driver

#154 2018-02-24 08:12:27

Re: Terrible performance regression with Nvidia 390.25 driver

#155 2018-02-24 08:34:26

Re: Terrible performance regression with Nvidia 390.25 driver

#156 2018-02-26 02:20:44

Re: Terrible performance regression with Nvidia 390.25 driver

#157 2018-02-26 06:15:23

Re: Terrible performance regression with Nvidia 390.25 driver

#158 2018-02-28 18:48:05

Re: Terrible performance regression with Nvidia 390.25 driver

#159 2018-02-28 19:33:11

Re: Terrible performance regression with Nvidia 390.25 driver

#160 2018-03-01 16:49:09

Re: Terrible performance regression with Nvidia 390.25 driver

#161 2018-03-01 23:18:51

Re: Terrible performance regression with Nvidia 390.25 driver

#162 2018-03-01 23:38:52

Re: Terrible performance regression with Nvidia 390.25 driver

#163 2018-03-02 13:34:29

Re: Terrible performance regression with Nvidia 390.25 driver

#164 2018-03-04 03:53:18

Re: Terrible performance regression with Nvidia 390.25 driver

#165 2018-03-05 01:29:22

Re: Terrible performance regression with Nvidia 390.25 driver

#166 2018-03-06 01:46:09

Re: Terrible performance regression with Nvidia 390.25 driver

#167 2018-03-06 08:10:35

Re: Terrible performance regression with Nvidia 390.25 driver

#168 2018-03-08 21:08:29

Re: Terrible performance regression with Nvidia 390.25 driver

#169 2018-03-08 21:17:12

Re: Terrible performance regression with Nvidia 390.25 driver

#170 2018-03-08 21:38:09

Re: Terrible performance regression with Nvidia 390.25 driver

#171 2018-03-09 05:48:56

Re: Terrible performance regression with Nvidia 390.25 driver

#172 2018-03-09 09:18:04

Re: Terrible performance regression with Nvidia 390.25 driver

#173 2018-03-09 12:45:24

Re: Terrible performance regression with Nvidia 390.25 driver

#174 2018-03-09 20:14:57

Re: Terrible performance regression with Nvidia 390.25 driver

#175 2018-03-12 20:02:02

Re: Terrible performance regression with Nvidia 390.25 driver

Board footer