kwin-lowlatency - NVIDIA testing thread

[tildearrow]

So I just released KWin-lowlatency 5.23.3-2 which finally brings unredirection back to the compositor.
I haven't tested on NVIDIA at all though since I've put my card away and it is difficult to get it back.

Share your test results here!

[DarkWav]

I will package 5.23.3 for openSUSE Tumbleweed now, and since I have an NVIDIA card, I should be able to do some testing there.

[ptr1337]

@tildearrow
I will built later kwin-lowlatency on arch and going to test with the latest nvidia driver.

I also got a repo, where can the built package found, when i compiled it.

Maybe add it to the wiki if you want to.
https://wiki.cachyos.org/en/home/Repo

[ptr1337]

Compiled completly smoothly on my server in a chroot. Also with -march=x86-64-v3 for the optimized repo. Just need to wake up and go to my rig and get maybe the good old times back!

[ptr1337]

Runs also at me quite good so far, didnt tested gaming. I use two monitors with different refresh rates (240Hz and 144Hz).
But desktop feels for better, could be also placebo.
I will test more today, thanks for your release.

[DarkWav]

Well, so far no major Issues, very stable on X11!
Wayland works as well, but ofc with the usual NVIDIA buginess.
I couldn't get full-screen undredirection to work with Minecraft yet, if I enable the compositor the performance is still horrible compared to the compositor being disabled, but maybe that's just Minecraft being weird.
I've also published 5.23.3 to OBS, should be available in home:DarkWav:kwin-lowlatency repos shortly.

[ptr1337]

@DarkWav

There is for wayland on nvidia a patch, which definitly helps with wayland on nvidia. Need to be applied on qt5-wayland.

From e227db9b9a6f13c3a97cf719110827a20926b68e Mon Sep 17 00:00:00 2001
From: Erik Kurzinger <ekurzinger@nvidia.com>
Date: Mon, 27 Sep 2021 14:00:49 -0400
Subject: [PATCH] Don't block in QWaylandDisplay::flushRequests

QWaylandDisplay::flushRequests calls wl_display_prepare_read immediately
followed by wl_display_read_events, which will simply read in any events
that are already available on the socket. Hence, this will typically be
a non-blocking operation, and the rest of the wayland platform code
assumes that to be the case.

However, if another thread has also called wl_display_prepare_read,
wl_display_read_events will block until that other thread has also
called wl_display_read_events (or wl_display_cancel_read). If the other
thread decides to wait until new events are available on the socket
(e.g. using poll) before calling wl_display_read_events, this will force
our thread to wait as well, potentially causing the application to hang.

Recent versions of the NVIDIA EGL driver do exactly this, and it renders
QtQuick applications in particular unusable.

As a fix, this change modifies flushRequests to call poll on the display
fd, with a timeout of 0, to check whether there is any data immediately
available to read. If there is, we can be confident that any other
threads that may have also been polling the fd will have been unblocked,
and therefore that wl_display_read_events will return right away. On the
other hand, if there is no data ready to read, flushRequests will call
wl_display_cancel_read instead.

After reading any available events, it will then dispatch the default
queue along with all frame queues. It's not necessary to call
wl_display_read_events again for each frame queue as the current code
does.

Pick-to: 6.2 5.15
Change-Id: I77b2540a809c3a9dbe4532134a5b418f6731e41a
---

diff --git a/src/client/qwaylanddisplay.cpp b/src/client/qwaylanddisplay.cpp
index aeb5f4b..5c3509f 100644
--- a/src/client/qwaylanddisplay.cpp
+++ b/src/client/qwaylanddisplay.cpp
@@ -225,10 +225,25 @@
 
 void QWaylandDisplay::flushRequests()
 {
-    if (wl_display_prepare_read(mDisplay) == 0) {
+    // first dispatch any pending events on the default queue
+    while (wl_display_prepare_read(mDisplay) != 0) {
+        wl_display_dispatch_pending(mDisplay);
+    }
+    wl_display_flush(mDisplay);
+
+    // then check if there are any new events waiting to be read
+    struct pollfd pfd;
+    pfd.fd = wl_display_get_fd(mDisplay);
+    pfd.events = POLLIN;
+    int ret = poll(&pfd, 1, 0);
+    if (ret > 0) {
+        // if yes, read them now
         wl_display_read_events(mDisplay);
+    } else {
+        wl_display_cancel_read(mDisplay);
     }
 
+    // finally, dispatch the default queue and all frame queues
     if (wl_display_dispatch_pending(mDisplay) < 0)
         checkError();
 
@@ -236,14 +251,9 @@
         QReadLocker locker(&m_frameQueueLock);
         for (const FrameQueue &q : mExternalQueues) {
             QMutexLocker locker(q.mutex);
-            while (wl_display_prepare_read_queue(mDisplay, q.queue) != 0)
-                wl_display_dispatch_queue_pending(mDisplay, q.queue);
-            wl_display_read_events(mDisplay);
             wl_display_dispatch_queue_pending(mDisplay, q.queue);
         }
     }
-
-    wl_display_flush(mDisplay);
 }
 
 void QWaylandDisplay::blockingReadEvents()

[tildearrow]

I couldn't get full-screen undredirection to work with Minecraft yet,

On X11? Hmm.... In a bit I will add some debug code to check which window may be blocking it because sometimes tiny transparent windows get on the way and block unredirection...

[DarkWav]

@tildearrow Did some debugging with 5.23.3-3 and found out the following:

1. Opaque detection seems quite buggy, detects browser fullscreen video windows as non-opaque even though they are, but nevertheless browser fullscreen video should always be composited to prevent screen tearing anyway.
2. Minecraft doesn't use Variable Refresh Rate when in Fullscreen with composior enabled and therefore tries to do half-sync at exactly 82.5FPS (My screen is 165Hz).
   Even though fullscreen unredirection probably works correctly, the NVIDIA driver fails to detect that VRR is applicable in that case and keeps VRR disabled for the Minecraft Window, and because of that, Minecraft falls back to traditional V-Sync methods instead of G-Sync Compatible, in my case to Half-V-Sync (locking framerate at half the monitor's refresh rate), and that makes performance seem bad. Complicated but makes sense xD

[tildearrow]

1. Yep, indeed. Browser and Konsole are marked as non-opaque (but does the "force unredirect for non-opaque windows" setting work?).
2. Hmmm... that is not normal. I remember when KWin-lowlatency used to have a bug in NVIDIA which made it sync at exactly half the refresh rate.... Could you test with overlay on in nvidia-settings and see if it says BLIT or FLIP?

[ptr1337]

Cause The FPS issue i will test later with rocket league.

[maxiberta]

Nice! Just updated the Ubuntu PPA with 5.23.3 builds for Impish 21.10.

Testing on a GeForce GTX 1650 Mobile laptop with internal panel @ 60Hz, and two external monitors @ 60Hz and @ 120Hz on X11.

The "OML sync control" vsync feels particularly smooth at 120Hz. With the caveat that "Allow Flipping" needs to be disabled in nvidia-settings in order to get the higher refresh rate (this is the same as with stock kwin). Otoh, env vars KWIN_X11_FORCE_SOFTWARE_VSYNC=1 and KWIN_X11_REFRESH_RATE=120000, needed with stock kwin to achieve 120Hz, are not needed with kwin-lowlatency afaict.