Mesa OpenGL Threading Messed Up Cursor Handling With KDE Wayland - Fixed Now

[shmerl]

How is that not a problem with KDE if it only happens with kwin?

[MadCatX]

How is that not a problem with KDE if it only happens with kwin?

You don't know that it's only happening in KWin and wayland. It could easily be that cursor issues are easy to spot and you will run into them even if you're not a gamer, hence it got reported early. There could be other issues about to pop up once the globally enabled threading hits stable repos.

[oiaohm]

So this is a workaround that went in Mesa. And what about an actual fix? Is it mesa that needs to be fixed or kwin_wayland?

It's another case of KDE's "it's their fault, out ours"

I agree with the above that this hardly a fix. While there isn't really a need for KDE to use GL threading and disabling it is arguably a perfectly fine solution, there should be an attempt to understand why it's happening (and perhaps there was but that was omitted from the article), because if this can affect something as basic as a cursor, imagine what other visual glitches may happen where we won't know if GL threading is to blame.

Well, we can't yet rule out whose fault it really is. There must be a reason why proprietary drivers and other OSes don't do GL threading, on the other hand, KDE's cursor so far seems to be the only thing that experiences glitches from it.

Nothing is that simple. GLthreading that Mesa is doing is not part of the Opengl Standard. Also Nvidia under windows does enable per application threading of opengl that is very much like Mesa Glthreading default but with Nvidia is off unless particularly turned on.

The reality here both KDE and Mesa are to blame here. KDE code is not thread safe on Opengl code paths so you cannot get the most performance. Mesa threading glthread with opengl is outside Opengl specification so does result in some non conformant behaviors.

Yes Mesa with glthread enabled does result in failing some of The Khronos Group Conformance Tests for opengl.

So if the issue is fixed by turning glthread off with Mesa3d most likely KDE Wayland is in the right by the official Opengl Standard. But do we want KDE Wayland to be working limited to the Official Opengl Standard most likely no instead we should want KDE Wayland to come thread safe in it own right so opengl layer can make better usage of cores.

Also something else to be aware of the list that KDE Wayland has been added to to make glthread off for this application is not the only application on it. Some opengl applications that cannot be updated for glthread or Nvidia equal under windows will have to be left on the no threading list.

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf#L640

Yes its 3 at the moment. DeusExMD. F1 2015 and KWin Wayland. But we should expect this list to grow with more testing and more issues found. Also the mesa system and the Nvidia system these working around under windows also has no support for for updating application can using the same name. Basically you cannot go if application is under X version work around required after X version work around not required.

Big take away glthread is not to opengl standard. Testing of mesa glthread turns out for majority of applications tested so far glthread in mesa works and gains performance by using it without any code changes. Problem here there is a small minority of applications that depend on the formal Opengl define behavior.

So yes glthread is Mesa3d fault for broadly enabling. Its also could argue KDE fault for not having proper threaded opengl safe code but when the change is not to opengl standard behavior and the code can have worked perfectly as is for decades its not KDE fault for having the issue. Now if KDE does not update there code base to support opengl being threaded in future then it is KDE fault.

This is not black and white this is a case both sides are guilty.

[shmerl]

I wish KDE would use Vulkan instead of OpenGL.

[oiaohm]

As a KDE user I would agree on that. On Wayland KDE cursor movement is really buggy. For example, a game locked to 60 fps and minimized cripples cursor movement on desktop to the same 60 fps - just because it is opened. Though any other windowed app can run 144 FPS at the same time. That never happens on X11 session.

https://gitlab.freedesktop.org/mesa/...ults.conf#L654

That in fact links to a lot bigger issue.

<option name="adaptive_sync" value="false" />​

Yes the mouse cursor not doing under X11 is true because the X11 server is doing the cursor rendering but there is a rendering issue that is also still there under X11 that is linked to that problem around adaptive_sync handling. Yes that is a lot more common most X11 compositors don't correctly handling application fps changes for the most power effective outcome instead run at a constant balls to wall FPS. Yes this is some of the reason why Linux on laptops has shorter battery life than it should.

This is why you have to be so careful with Wayland vs X11 compares. Sometimes Wayland compositor highly visible bad performance is linked to X11 compositor more hidden bad performance. Yes where the problems are two sides of exactly the same coin.

[user1]

As a KDE user I would agree on that. On Wayland KDE cursor movement is really buggy. For example, a game locked to 60 fps and minimized cripples cursor movement on desktop to the same 60 fps - just because it is opened. Though any other windowed app can run 144 FPS at the same time. That never happens on X11 session.

TBH, I experienced the exact same behavior on Gnome Wayland. I think this is generally a Wayland issue because of the software cursor.

[middy]

why does this affect wayland kwin and not x11 kwin?

[oiaohm]

why does this affect wayland kwin and not x11 kwin?

X11 Mouse cursor is normally drawn by Xserver no the kwin itself. Under Wayland kwin is drawing the mouse cursor itself. You can force kwin to draw the mouse cursor by enabling so called software mouse cursor and have the same problem appear under x11.

So this is not 100 percent unique Wayland issue. Just under X11 you are unlikely unless you are doing some form of diagnostic to turn on kwin software rendering of cursor.

There are lots and lots of cases where issue in face visible under Wayland with gnome or kde turns out to be still there under X11 just need extra options enabled to make it happen.

[mdedetrich]

Multi threading in OpenGL is just broken on one level or another. Its not just with desktop compositing, it also happens purely within OpenGL games. Although there are ways to do it, historically the results have been subpar and the number of games that have managed to get multiple threads working with GL rendering you can fit on a single hand (note that although games obviously have historically used multiple cores, that wasn't necessarily for rendering but rather AI/Physics etc etc).

[oiaohm]

Multi threading in OpenGL is just broken on one level or another. Its not just with desktop compositing, it also happens purely within OpenGL games. Although there are ways to do it, historically the results have been subpar and the number of games that have managed to get multiple threads working with GL rendering you can fit on a single hand (note that although games obviously have historically used multiple cores, that wasn't necessarily for rendering but rather AI/Physics etc etc).

https://gitlab.freedesktop.org/mesa/...ults.conf#L415 to Line 650 are all the ones that glthread was turned on because it works. You hand has to have a lot of fingers. We are talking over 50 cases where it works.

Multi threading with Opengl normally only works if the opengl layer like Mesa3d or Nvidia closed source you are using happens to be multi threaded and happens to allow the feature.

The number who got it working on top of Opengl implementation locked to single threaded you could count on 1 hand for any advantage most cases slower. This is the same as the Linux kernel big kernel lock problem except this is Opengl Implementation big single lock. Things do change over time.

Multi threading opengl at the implementation layer brings out particular corner cases that opengl standard says should be safe to-do but are unsafe once opengl is multi threaded as long as applications don't do those things everything is good. KDE Wayland it the case the mouse cursor drawing is using one of the corner cases..

https://download.nvidia.com/developer/presentations/2006/gdc/2006-GDC-NV_Multi-Thread-Best-Practices.pdf

mdedetrich the reality here lot of opengl applications are written for multi threaded backend because the were coded matching Nvidia Best Practices. Remember Nvidia opengl binary has multi threading this is not to the opengl specification.