Closed tam1m closed 2 years ago
Thanks for the bug report.
Can you please return the output of xrandr
? I need to know the monitors' refresh rates.
Sure, thats my monitor configuration
Screen 0: minimum 8 x 8, current 3600 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1920x1080+1680+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 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 473mm x 296mm
1680x1050 59.95*+
1600x1000 60.00
1440x900 59.89
1280x1024 75.02
1280x960 60.00
1152x720 60.00
1024x768 75.03 60.00
800x600 75.00 60.32
640x480 75.00 59.94
144 Hz.......
Anyway, I have pushed some commits. Can you please test on the latest Git version and tell me if "Hope for the best" improves the situation?
I just tried the latest git version, but nothing changed. I also tried both monitors on 60 Hz and only a single monitor on 60 Hz, but the problem persists regardless of the configuration.
This is indeed very strange as I haven't been able to reproduce this in my system (tried AMD, NVIDIA and even NVIDIA under multi-monitor, but could not reproduce).
Can you try a single monitor on 60Hz and then after setting the refresh rate, restarting the compositor?
Ok so, I tested a few configurations including single monitor set to 60 Hz. That didn't change anything.
But then I created a completely new user, logged in and kwin_lowlatency works perfectly fine. No problems at all. It must be something in my user config, but I can't find it.
Things I tried:
Any idea what else it could be?
Edit:
I found the it. I had the "Allow Flipping" switch disabled in nvidia-settings. Turning it back on fixes everything, but in turn, performance is way worse. Moving windows etc. is really stuttery (feels more like 60Hz than 120+) and the latency increases noticeably.
You can enable the "Show FPS" effect to confirm that's the case, and if so, try tweaking the min/max latency reduction in the Compositing settings.
If the latency does increase, I'll have to look into that...
(by the way, have you disabled any of the "Force Composition Pipeline" options? Hope you did)
Well I spoke too soon. When I enabled flipping while testing, it worked, but after a reboot the problem.
This is a problem because so far I have been unable to reproduce this, and the worst is that if this is related to the 144Hz monitor then this will be much more complicated due to the fact I don't have a 144Hz monitor and can't afford one at the moment. I will try harder to reproduce this problem in around 1-2 hours when I come back to my machine, but in the meanwhile:
Can you print the output of qdbus org.kde.KWin /KWin supportInformation
, and the list of active desktop effects and KWin scripts? (or better yet, your kwinrc (strip/remove any file paths or sensitive information first)?)
Sorry I couldn't get back to you earlier.. timezones..
This is a problem because so far I have been unable to reproduce this, and the worst is that if this is related to the 144Hz monitor then this will be much more complicated due to the fact I don't have a 144Hz monitor and can't afford one at the moment.
I don't think it is related to 144Hz since it also happens with a single 60Hz monitor.
Can you print the output of qdbus org.kde.KWin /KWin supportInformation, and the list of active desktop effects and KWin scripts? (or better yet, your kwinrc (strip/remove any file paths or sensitive information first)?)
kwin_supportinformation.txt kwinrc.txt
One thing I noticed in the Kwin support information is this
Screen 0:
---------
Name: DVI-I-1
Geometry: 1680,0,1920x1080
Scale: 1
Refresh Rate: 59.9543
Screen 1:
---------
Name: HDMI-0
Geometry: 0,30,1680x1050
Scale: 1
Refresh Rate: 60
The refresh rate for screen 0
is wrong here. Kwin doesn't seem to know that the monitor is running at 144 Hz right now
Painting blocks for vertical retrace: no
...what? How is it "no"? kwin-lowlatency always blocks to wait for VBlank. How did it come up with "no"?
Can you try setting the VSync mechanism to "SGI video sync with horrible hack" and reporting the output of qdbus org.kde.KWin /KWin supportInformation
again? This may be the culprit.
Wow... I just realised GLPreferBufferSwap=n
in kwinrc aka "Tearing Prevention ("vsync")" was set to "Never" the whole time. Which is strange, because I never touched that setting. My problems started right after the update to 5.16.5. Only then did I even open the settings. Did you try to reproduce the bug with my kwinrc? After setting it to "Automatic" things are working. Although, I do get a lot of tearing right now! I don't really have the time to look into it at the moment, but it might be unrelated to this issue(?).
Is kwin_lowlatency "breaking", when vsync is completly off, intended behavour? I feel like, it must have been working fine before, since my configuration did not change at all. Just updated to the latest version and that was, when things began to break.
This was also the reason for Painting blocks for vertical retrace: no
Wow... I just realised GLPreferBufferSwap=n in kwinrc aka "Tearing Prevention ("vsync")" was set to "Never" the whole time.
If that's the cause of this bug, then that's still unusual...
Although, I do get a lot of tearing right now!
Try enabling "Sync to VBlank" in your NVIDIA settings? I see they're turned off.
If that's the cause of this bug, then that's still unusual...
This is definitely it. As soon as "Tearing Prevention" this is set to "never", things stop working.
Hi, this problem is especially annoying with websites of banks (in germany) displaying a so called 'flicker-code' that you must read with a special external device from screen to generate a banking-transaction number (see: Sm@rtTAN plus) Having the default setting (tearing prevention: automatic), the device won't reconize the code. Setting it to 'off' or 'only when cheap' fixes the problem with the flicker codes for now. Is it possible to have those settings for selected applications only? (btw, this was on a laptop with intel graphics)
Sorry. No time. Fixing when I can
@tildearrow
This has become 100% reproducible for me since the 5.18 update. Before, it would only appear when I had very few, if any, windows opened. Since 5.18, all animations run at extremely slow speeds.
This is using the 'none' vsync mechanism, using nvidia 440.48.02.
Using the SGI video sync hack mitigates the issue.
@prefanatic Time to switch to the NVIDIA card and test... but... "SGI video sync hack"? Do you mean the SGI video sync or SGI video sync with horrible hack?
@tildearrow
With the "horrible hack". The last option in the list of vsync mechanisms.
I can't fix this for now.... I have no time and I am not feeling happy so, yep...
I have temporarily set it to horrible hack by default on 5.18.2... until I figure out what causes this problem...
Oops, sorry. Wrong label.
Check if you have triple buffering enabled. Enabling it can cause weird issues.
$ cat /var/log/Xorg.0.log | grep TripleBuffer
What does this print?
Also check whether you have exported environment variables that were popular in the past to fix kwin nvidia bugs, like KWIN_TRIPLE_BUFFER
or __GL_YIELD
. They can also cause issues.
@realnc
I've not enabled triple buffering, nor exported those two variables.
@tildearrow
I updated to 5.18.1 (https://github.com/tildearrow/kwin-lowlatency/commit/697c7eff129171432428ca0dbc249011a8fcab4a) a couple days ago, have not reproduced it since. It seemed to only crop up for 5.18? Works perfectly fine right now.
@prefanatic Wait how? OK, I got to look at this when I come back home.
In the meanwhile, can you tell me if this issue reproduces with the SGI video sync VSync mechanism?
@tildearrow
The issue does not reproduce with the SGI video sync mechanism.
I've taken time to drop back down to the first implementation on 5.18.0, and am unable to reproduce it again. Incidentally, I forgot I've since updated my nvidia drivers from 440.48.02 to 440.59. Maybe that's a factor here.
I may not be able to tonight, but I'll drop back down to 440.48.02 and see if I can get it slow again there.
I got this slow animation issue while testing the various "vsync mechanism" settings on 5.18.2 due to bug https://github.com/tildearrow/kwin-lowlatency/issues/63. The issue disappeared after restarting kwin with kwin_x11 --replace &
.
To me it looks like some kind of settings issue rather that an issue with nvidia drivers. If you're still on 5.18.0, try changing that setting without restarting kwin and see if you can trigger the behavior. Then try current master branch (there's a settings initialization fix after the 5.18.2 release) that might have fixed it without the need to restart kwin.
@prefanatic Amazing! It's good to see that mysterious issue g-
@realnc ...oh no, not again... :< Sorry I got no time now due to class and because the NVIDIA driver stopped working somehow (probs 'cuz I have AMDGPU-PRO installed and that conflicts somehow) but after I am done I need to look at this.... either at night or midnight when I am free.
In the meanwhile can you try removing the __GL_MaxFramesAllowed
code in plugins/platforms/x11/standalone/glxbackend.cpp
and use the SGI video sync mechanism and report if that fixes the issue? I have a feeling this might be....
Great. Now I can't reproduce it no matter what >.< The closest I've gotten to is triggering a state where I get very slow scrolling in Firefox when I mess with the GLPreferBufferSwap
setting in kwinrc, which is fixed by restarting Firefox. However, this also happens with vanilla kwin so it's irrelevant here.
As for the half vsync issue when using the "horrible hack" setting, commenting out that line indeed prevents it from happening.
@realnc According to the original reporter, it would not reproduce under normal KWin.
Different issue. Shouldn't have mentioned it then.
Ugh, have tried for a fair amount of time and could never reproduce the issue... :< I really don't know what could cause it anymore...
Slightly reproduced under AMD by using "None" VSync mechanism and VSync set to Never. I don't know if this is related.
I am able to reproduce the slowed animations on my system:
Manjaro KDE 5.18.5 w/ Liquorix kernel GTX 1060 3GB w/ nvidia-beta-dkms 440.82 driver kwin-lowlatency 5.18.5-3
Tested with Show FPS
and Wobbly Windows
Desktop Effects, as well as testufo on Vivaldi
kwinsupportinfo kwinrc kwin-lowlatency settings that work, but causes OBS artifacts due to requiring Allow Flipping (Force Composition Pipeline is also required to prevent slow animations)
Some notes, including a table of the notable options and their effects:
Painting blocks for vertical retrace
is always no
unless I set KWin's Tearing prevention ("vsync")
to anything but Never
, no matter what other setting I changeSGI video sync with horrible hack
and Force Composition Pipeline
yields near perfect results without OBS flickering, but caused my display to be either frozen or stuck black after the screen turns off from idling. Changing it to anything else fixes that. I saw a segfault in the boot log while using that option that may be relatedOK, so it appears this issue is in fact caused by disabling VSync as this reproduces under AMD too.
Successfully reproduced when trying to open a combo box. It appears that the animation timer goes crazy when we're rendering too fast (e.g. no vsync). Let's try a sort-of fix.
Please try commit 7afcdf0e4. This is a workaround.
Wait, no, please do not try. I made a mistake.
OK, everything fine. Please try with d76fb9af8503958dccd8164128d132455af4df0d and report back.
KWin-lowlatency 5.19.1 released with a possible workaround...
Closing as the rewrite changed everything. Reopen if it still occurs.
Video of the problem
Since the 5.16.5 update, kwin-lowlatency has issues with animations on my system. The video demonstrates whats happening. Animations are being played really slowly or even getting stuck, until something else on the screen is drawn. Like selecting something on the desktop or moving another window while the animation is being played, fixes the animation. Even recording the screen altered this behaviour quiet a bit. Animations were being played more smoothly, depending on the recordingframerate, although still still stuttery and not at the right speed.
This happens when the vsync mechanism is set to anything else, but "SGI video sync with horrible hack" ~or backend set to Xrender~. Also disabling my second monitor does not change this behaviour. Upstream kwin works as intended on my system.
Let me know, if you need any more information or testing.
edit: Using Xrender shows the same problem Problem.
My system: Arch Linux Nvidia 435.21 (GTX 970) Intel i7-8700k kwin 5.16.5 plasmashell 5.16.5