Bug 433094 - No way to disable tearing prevention
Summary: No way to disable tearing prevention
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: 5.21.0
Platform: Archlinux Linux
: NOR minor with 3 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-02-17 17:18 UTC by fynnbwdt
Modified: 2022-10-21 07:55 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fynnbwdt 2021-02-17 17:18:28 UTC
SUMMARY
The new kwin version (5.21.0) is unusable for me, I'm running a dual monitor setup, one monitor with 144hz the other 60hz.
In the old kwin version there was an option to disable tearing prevention which is now missing. 
Without disabling tearing prevention moving windows feels very sluggish and seems like it's capped to 60hz. 
I have tried numerous workarounds (such as adding "MaxFPS=144" to the kwinrc, setting the environment variable "__GL_SYNC_DISPLAY_DEVICE" to my 144hz monitor, playing around with NVIDIA Settings (also tried Force(Full)CompositionPipeline, trying out all of the new vsync options, basically everything there is) but nothing helps.
Would it be possible to bring back an option to disable tearing prevention?

STEPS TO REPRODUCE
1. Update to new kwin version

OBSERVED RESULT
No way to disable tearing prevention.
Moving windows and other compositor related things seems to be capped to 60FPS.

EXPECTED RESULT
An option to disable tearing prevention like on the old version

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux, Kernel 5.10.10, KDE 5.21.0
(available in About System)
KDE Plasma Version: 5.21.0
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Comment 1 Méven Car 2021-02-18 06:15:28 UTC
Is a Wayland session affected ?
Comment 2 Szczepan Hołyszewski 2021-02-18 07:21:20 UTC
It is completely irrelevant whether Wayland session is affected or not.

I know you guys promote Wayland and would be inclined to answer "hey, if Wayland session isn't affected, switch to Wayland", but the reality for many nVidia users is that Wayland Does Not Work And Never Has.
Comment 3 Vlad Zahorodnii 2021-02-18 08:05:43 UTC
This option was removed in 5.21 because now compositing is synchronized to hardware vblank events and the screens are repainted as close as possible to the next vblank. It is up to Xorg and drivers what display buffer swaps are synchronized to.

If you have an NVIDIA video card, setting __GL_SYNC_DISPLAY_DEVICE to a 144hz monitor should still work though.

> Is a Wayland session affected ?
On Wayland we have proper support for mixed refresh rate setups.
Comment 4 fynnbwdt 2021-02-18 08:45:20 UTC
__GL_SYNC_DISPLAY_DEVICE=DVI-D-0
VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DVI-D-0

I have this in /etc/environment, it does not help at all.
It didn't help on 5.20.5 nor does it help on 5.21.0.

I understand that you want to stick to your new method of synchronizing but why can't there be an option to not really synchronize at all?

Also wayland is not an option for me since I have an nvidia card
Comment 5 Vlad Zahorodnii 2021-02-18 09:54:03 UTC
It seems like it's a driver bug. __GL_SYNC_DISPLAY_DEVICE has no any effect. If it's set to the fastest monitor, buffer swaps are still capped to the slowest monitor.

(In reply to fynnbwdt from comment #4)
> I understand that you want to stick to your new method of synchronizing but
> why can't there be an option to not really synchronize at all?

Because compositing is no longer driven by a timer as it was in previous versions. Also, on Wayland, vsync is always on.

Not sure, maybe we just need to introduce an X11-specific environment variable to disable vsync and force kwin to use software vblank events instead.

> Also wayland is not an option for me since I have an nvidia card
Comment 6 fynnbwdt 2021-02-18 09:55:38 UTC
> Not sure, maybe we just need to introduce an X11-specific environment variable to disable > vsync and force kwin to use software vblank events instead.

This would be a nice solution
Comment 7 Bug Janitor Service 2021-02-18 12:20:50 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/707
Comment 8 Vlad Zahorodnii 2021-02-18 12:42:39 UTC
With !707, it will be possible to disable syncing to vblanks and make kwin not use hardware vblanks.

env KWIN_X11_REFRESH_RATE=144000 KWIN_X11_NO_SYNC_TO_VBLANK=1 KWIN_X11_FORCE_SOFTWARE_VSYNC=1 kwin_x11
Comment 9 fynnbwdt 2021-02-18 19:08:25 UTC
Just tested it, works like a charm! Thank you so much :D
Comment 10 Vlad Zahorodnii 2021-02-19 15:00:08 UTC
Git commit fb93037ca7c0d634d3cd38ae52c957f11cc39297 by Vlad Zahorodnii.
Committed on 19/02/2021 at 14:59.
Pushed by vladz into branch 'master'.

x11: Introduce an envvar to prevent sync'ing to vblanks

This can be useful if you want to ensure that the buffer swap operation
won't block.

M  +8    -3    src/plugins/platforms/x11/standalone/glxbackend.cpp

https://invent.kde.org/plasma/kwin/commit/fb93037ca7c0d634d3cd38ae52c957f11cc39297
Comment 11 Vlad Zahorodnii 2021-02-19 15:00:16 UTC
Git commit 45979ed46013999da781d912f93e0e644d19ff1f by Vlad Zahorodnii.
Committed on 19/02/2021 at 14:59.
Pushed by vladz into branch 'master'.

x11: Introduce an envvar to force software vsync

This can be useful for debugging purposes and for people wishing to ramp
up the refresh rate on their setups with different refresh rates.

M  +9    -6    src/plugins/platforms/x11/standalone/glxbackend.cpp

https://invent.kde.org/plasma/kwin/commit/45979ed46013999da781d912f93e0e644d19ff1f
Comment 12 Vlad Zahorodnii 2021-02-19 15:01:30 UTC
Git commit 70965e96ca459f18bbf08b3879ce599a68fa6ac5 by Vlad Zahorodnii.
Committed on 19/02/2021 at 15:01.
Pushed by vladz into branch 'Plasma/5.21'.

x11: Introduce an envvar to prevent sync'ing to vblanks

This can be useful if you want to ensure that the buffer swap operation
won't block.
(cherry picked from commit fb93037ca7c0d634d3cd38ae52c957f11cc39297)

M  +8    -3    plugins/platforms/x11/standalone/glxbackend.cpp

https://invent.kde.org/plasma/kwin/commit/70965e96ca459f18bbf08b3879ce599a68fa6ac5
Comment 13 Vlad Zahorodnii 2021-02-19 15:01:39 UTC
Git commit ea932230d94c72bd24b364bce5ccb4944a94342c by Vlad Zahorodnii.
Committed on 19/02/2021 at 15:01.
Pushed by vladz into branch 'Plasma/5.21'.

x11: Introduce an envvar to force software vsync

This can be useful for debugging purposes and for people wishing to ramp
up the refresh rate on their setups with different refresh rates.
(cherry picked from commit 45979ed46013999da781d912f93e0e644d19ff1f)

M  +9    -6    plugins/platforms/x11/standalone/glxbackend.cpp

https://invent.kde.org/plasma/kwin/commit/ea932230d94c72bd24b364bce5ccb4944a94342c
Comment 14 Gastón Haro 2021-03-18 15:48:27 UTC
How do we use this env vars. Previously I had disabled vsync because screen sharing through Zoom caused terrible screen flickering for people watching my screen. No I can't turn it off and thus I cannot use screen sharing with Zoom.
Comment 15 fynnbwdt 2021-03-18 15:50:51 UTC
Put this in your /etc/environment

KWIN_X11_REFRESH_RATE=144000
KWIN_X11_NO_SYNC_TO_VBLANK=1
KWIN_X11_FORCE_SOFTWARE_VSYNC=1
Comment 16 S. Christian Collins 2021-03-30 05:32:58 UTC
If you have two monitors at different refresh rates and an NVIDIA graphics card, I have found the following to result in buttery smooth, tear-free perfection:

1. In NVIDIA XServer Settings, disable OpenGL flipping, then set ForceCompositionPipeline=On for both displays (Display Configuration -> Advanced... will need to save to X.org configuration file).
2. Put the following in /etc/environment (144000 = 144 Hz, adjust accordingly to the highest refresh rate between your monitors):

KWIN_X11_REFRESH_RATE=144000
KWIN_X11_NO_SYNC_TO_VBLANK=1

This results in perfectly smooth, tear-free animation on the high refresh rate display, and lower framerate, still tear-free animation on the other display. Note that I am leaving out the "KWIN_X11_FORCE_SOFTWARE_VSYNC=1" setting, as adding it results in dropped frames.

Thanks to the kwin developers for making these options available!
Comment 17 Jason Straight 2021-07-21 18:40:23 UTC
(In reply to S. Christian Collins from comment #16)
> This results in perfectly smooth, tear-free animation on the high refresh
> rate display, and lower framerate, still tear-free animation on the other
> display. Note that I am leaving out the "KWIN_X11_FORCE_SOFTWARE_VSYNC=1"
> setting, as adding it results in dropped frames.

Can you tell me how you monitored for the dropped frames, or was it just an observation?

Also, how are you monitoring the FPS for kwin? With the built in compositor 'effect'? That shows me topped at 100fps, which is an improvement, but not the 144 I was expecting.
Comment 18 fynnbwdt 2021-07-21 18:45:13 UTC
```
export KWIN_X11_REFRESH_RATE=144000
export KWIN_X11_NO_SYNC_TO_VBLANK=1
export KWIN_X11_FORCE_SOFTWARE_VSYNC=1
```

I have this in my environment, I have not monitored the kwin-fps but am pretty sure that it's 144fps
Comment 19 fynnbwdt 2021-07-21 18:47:11 UTC
I just tested it with the built in effect and can confirm that it indeed just shows 100fps, however I'm pretty sure that it's 144fps in reality
Comment 20 sameidandpw 2022-01-18 03:40:31 UTC
...just why? This is a downgrade. Bring back that essential function. This is similar to Windows 8 FORCING desktop composition, and the resulting backlash.

It doesn't matter how well you implement VSync, it introduces latency and not everyone wants it.
It's known to cause stutters in many programs.
It actively stifles high Hz refresh rate users.
This change also made the quick and useful KWin "Suspend Compositing" shortcut completely useless, a dead function.
Comment 21 Nate Graham 2022-01-18 20:08:28 UTC
Re-opening the bug report doesn't revert the change or even encourage anyone to do so (it generally has the opposite effect). I would recommend that you start a conversation about this in on the plasma-devel@kde.org mailing list.
Comment 22 pcoop@tuta.io 2022-04-12 07:06:35 UTC
(In reply to fynnbwdt from comment #18)
> ```
> export KWIN_X11_REFRESH_RATE=144000
> export KWIN_X11_NO_SYNC_TO_VBLANK=1
> export KWIN_X11_FORCE_SOFTWARE_VSYNC=1
> ```
> 
> I have this in my environment, I have not monitored the kwin-fps but am
> pretty sure that it's 144fps
export KWIN_X11_NO_SYNC_TO_VBLANK=1
export KWIN_X11_FORCE_SOFTWARE_VSYNC=0
worked for me. I even had to force disable software vsync & then go with nvidia's pipelining to fix double vsync issue.
Comment 23 Vaclav Honzik 2022-09-15 14:20:36 UTC
(In reply to S. Christian Collins from comment #16)
> If you have two monitors at different refresh rates and an NVIDIA graphics
> card, I have found the following to result in buttery smooth, tear-free
> perfection:
> 
> 1. In NVIDIA XServer Settings, disable OpenGL flipping, then set
> ForceCompositionPipeline=On for both displays (Display Configuration ->
> Advanced... will need to save to X.org configuration file).
> 2. Put the following in /etc/environment (144000 = 144 Hz, adjust
> accordingly to the highest refresh rate between your monitors):
> 
> KWIN_X11_REFRESH_RATE=144000
> KWIN_X11_NO_SYNC_TO_VBLANK=1
> 
> This results in perfectly smooth, tear-free animation on the high refresh
> rate display, and lower framerate, still tear-free animation on the other
> display. Note that I am leaving out the "KWIN_X11_FORCE_SOFTWARE_VSYNC=1"
> setting, as adding it results in dropped frames.
> 
> Thanks to the kwin developers for making these options available!

Thanks this fixes it for me, finally it is same responsiveness as in Windows