You are not logged in.
Hi
I've installed Arch a couple of days ago with Gnome desktop enviroment, I've also installed nvidia drivers and checked it with glxinfo that it's working. Everything works perfectly except that windows and scrolling tend to lag at random frequent times. I've tried so far disabling every extension, putting nvidia kms into grub and mkinitcpio as the wiki suggested, enabling both Force Composition Pipeline and Force Full Composition Pipeline, switching between linux and linux-lts kernel. The scrolling stutter mostly occurs in browsers, I tested the stock gnome browser, firefox, chromium, all three stutter. This is the most annoying aspect of it that I just can't tolerate. Out of curiosity I booted Pop OS live usb just to see if gnome there is still stuttery, and to my suprise it was only a very minor stutter, almost Windows 10 amount of very light stutter because of webpage loading. However when I switched there to adwaita to replicate a gnome like enviroment, the stuttering returned, it wasn't that bad like on arch but still very noticeable. Is this an arch or gnome issue, or just a bad driver setting?
Example of the issue on arch: https://streamable.com/wzpc3p
Any help is appreciated, thank you for advance!
Last edited by w00dey (2021-06-19 21:52:58)
Offline
Did the live distro maybe run on nouveau (& wayland)?
Sanity check:
echo $XDG_SESSION_TYPE
The video doesn't look like "stutter" - the output seems to stall and the skip a bunch of frames.
Please post your xorg log and try to enable triple buffering, eg. /etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
Identifier "Default nvidia Device"
Driver "nvidia"
Option "NoLogo" "True"
Option "CoolBits" "24"
Option "TripleBuffer" "True"
EndSection
Offline
I checked it and I'm running on x11 and with nvidia drivers. I forgot to mention but I even disabled the wayland removal option from the gdm config and booted wayland to test the frameskip but in wayland it was much worse.
I've enabled triple buffering and the frameskip still occurs unfortunately.
Here are the xorg logs:
Xorg.0.log https://pastebin.com/tymiaWY1
Xorg.1.log https://pastebin.com/YHcW1Uhd
Offline
I checked it and I'm running on x11 and with nvidia drivers.
Also on PopOS?
I've enabled triple buffering
Not according to the logs you posted?
(Shadowed by your /etc/X11/xorg.conf?)
Does PopOS also ship gnome40?
I switched there to adwaita to replicate a gnome like enviroment
Does the reverse (using whatever theme PopOS uses by default on arch) have a similar (but reverse) effect?
Offline
I've enabled triple buffering also in xorg.conf and after a reboot I checked the logs and now triple buffering is enabled, but the frameskip still persists. PopOS has 3.38 if I remember correctly, but I've installed arch before the gnome 40 update and the issue was still there back then.
I've installed pop-theme from AUR and set it in gnome tweaks, the frameskip still occurs.
Last edited by w00dey (2021-04-09 22:30:51)
Offline
Thus to spot the difference and isolate the cause: does the PopOS live system use the nvidia or the nouveau driver?
(in doubt check "lsmod")
Offline
I use the liveusb with nvidia proprietary drivers and also checked: it's running x11 and it's on nvidia 460.67 just as my arch.
I also checked it doesn't have triple buffering enabled.
Link to the pop xorg log maybe it has any useful information: https://pastebin.com/ZF50i1md
Offline
As for the browsers, do you expericen the same if you disable "smooth" scrolling? (as eg. in chrome://flags/#smooth-scrolling )
Offline
I've tried that a few days ago, and I tried that now, it does not change anything unfortunately. Also in firefox I tried changing the renderer to opengl and webkit, but the frameskip still occured. Also I would like to point out that this frameskip happens in every app I open to a degree, for example in discord scrolling in a chat is also very jerky and moving the window around. I also noticed that especially if I move windows or go to overview menu, the more opened windows I have, the more stutter occurs. It's driving me nuts because this problem converts an otherwise much more fluid and faster DE than windows into a stuttery mess.
Offline
I forgot to mention that I also read through a couple of gnome bug reports regarding similar issues, and one solution I've found is to install an extension called wandering pixel that changes 1 pixel frequently in the top bar to force gnome to refresh the whole screen always. However in my case it did nothing, the frameskipping was exactly the same as before
Offline
Is this related to (mouse) input or does it also happen when eg. playing a movie in mpv?
Offline
I checked this because before I didn't notice it, I think because I watched 30fps videos and the stutters are harder to notice there. I watched a few youtube 60fps test videos and there it's still hard to notice, but microstutters occur all the time throughout the video. I ripped the same video with youtube-dl and watched it in mpv as you recommended, and it played perfectly. I also tried scrolling in a browser with the keyboard and it still stuttered, I don't know how much effect has the mouse on that scenario.
Offline
Another thing I noticed, if mpv is not full screen, it stutters.
Offline
You could try to
a) disable HW accelerated composition in the browser, eg. chrome://flags/#disable-accelerated-2d-canvas
b) not using gnome, but eg. openbox (and optionally picom, nb. that it defaults to xrender compositing)
to see how relevant compositor in general and mutter in particular are - or this is maybe indeed input related, because while
[ 5.535] (==) NVIDIA(0): Silken mouse disabled
the cursor does seem to hang w/ the window/output in your video and that should™ not happen if it's only output related.
In doubt try
Option "HWCursor" "True"
in your config
Edit:
Another thing I noticed, if mpv is not full screen, it stutters.
"stutter" like "judder" or stutter like "the movie stalled for a second and then jumped to the next scene"? Does the audio stutter as well?
Last edited by seth (2021-04-10 13:14:23)
Offline
Okay, I tried putting HWCursor True into xorg.config, but it didn't solve the problem in gnome. I installed and ran openbox however, and firefox is very smooth, but it has very bad screen tearing, I also checked in 60fps test youtube videos the tearing, and interestingly it only occurs if I move the mouse on top of the video. However scrolling with keyboard also produces the screentear. I can't show it to you because when I try to capture the video, obs I think forces vsync on the desktop and the problem disappears.
Offline
Oh I just noticed your edit now, I tested mpv on gnome again to see audio issues. Audio is good both on youtube and mpv. It doesn't stop for a long minute, it stutters very similarly like the windows when I drag them.
I tried to record it but it stutters in obs also in fullscreen so I can't show you the difference, but irl in fullscreen the 60fps circle is completely smooth. But here's the recording to see how it stutters. https://streamable.com/vfwoml
Offline
xrandr -q
Tearing should™ go away w/ either forcing the full composition pipeline or using pcom in GL mode w/ active vsync - and at this point it will be interesting to see whether the stalls re-occur w/ vsync.
Offline
Here's the result of xrand;
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
1920x1080 60.00*+ 144.00 119.98 99.93
1440x900 119.85
1280x1024 119.96 75.02 60.02
1024x768 119.99 75.03 60.00
800x600 119.97 75.00 60.32 Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
1920x1080 60.00*+ 144.00 119.98 99.93
1440x900 119.85
1280x1024 119.96 75.02 60.02
1024x768 119.99 75.03 60.00
800x600 119.97 75.00 60.32
640x480 120.01 75.00 59.94
HDMI-0 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
1920x1080 60.00*+ 144.00 119.98 99.93
1440x900 119.85
1280x1024 119.96 75.02 60.02
1024x768 119.99 75.03 60.00
800x600 119.97 75.00 60.32
640x480 120.01 75.00 59.94
HDMI-0 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)640x480 120.01 75.00 59.94
HDMI-0 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
Forcing full composition pipeline solved the tearing seemingly, and videos were also very smooth with no stutter on youtube but after a reboot I tried to enable it again and then it just reduced the tears but didn't solve it. I tried turning it on and off and nothing happened, after about 2-3 minutes I tried again and now it works. Also what I've noticed is that forcing this adds a big amount of input lag, both keyboard and mouse feels pretty unresponsive.
.
Now before sending the reply, I just checked the preview quote and upon this new page load the screen is tearing again despite force full composition is still on.
Offline
Now I don't know what happened but this is exactly what happened upon the first try: First everything seems good and after a while the screen tearing returns and then again disappears for a couple of seconds and then again returns. Totally unpredictable.
Offline
The xrandr output is a bothched copy from the pager/terminal buffer? That's not the actual, literal output, is it?
Does the monitor support https://wiki.archlinux.org/index.php/Va … _on_NVIDIA ?
Offline
What do you mean by botched copy? I carefully selected every output after my command in the terminal and pasted it here. Can I send you this differently somehow? Sorry if these questions are somewhat noobish but I don't use Linux regularly for a long time, I've never encountered any other way of sending this beside teeing it into a file.
I have a somewhat older benq 144hz display from 2013-14, it doesn't have any gsync or freesync option if you mean this under variable refresh rate. I use it in 60hz mode in the desktop if it matters, I only use 144hz if I play some games on it.
Offline
xrandr -q | curl -F 'f:1=<-' ix.io
In general, don't c&p out of the terminal but redirect the output into a textfile (the normal problem is a pager aka "less")
The output in #18 is a mess where several lines are doubled and unreasonably intertwined - your "xrandr -q" output should absolutely not look like that.
Do the stalls happen if you drive the output at 144Hz?
Offline
Oh okay here it is: http://ix.io/2VE5
It might've been the openbox xfce terminal that did this because now on gnome the terminal output looks exactly the same as on the link
Yes, the stuttering still occurs exactly the same if I switch to 144hz.
Offline
There's something definitely wrong about how vsync works on the nvidia driver. I've been playing a bit with the nvidia settings and found that if I turn of the opengl flip and sync to vblank then I get screen tearing with the exact same pattern as the frameskip is skipping when I'm scrolling or moving windows.
Offline
Also I've checked mpv commandline logs and if I don't switch between fullscreen and windowed, there's not a single dropped frame. Is it possible that none of the frames are skipped, but the frame timing is inconsistent, thus the judder?
Last edited by w00dey (2021-04-11 00:02:21)
Offline