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

[d3coder]

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

It's designed to stutter even with hardware cursor.
If you want non-stuttering cursor, you will have tearing.

https://github.com/swaywm/sway/issues/4763#issuecomment-578462619

[ATFx]

Source?

KDE. This Article. The Driver Change. The History of Repetitive Flaws that shouldn't affect KDE like
such Driver Performance Improvements to an existing OpenGL Function/Implementation doesn't imply the Desktop Environment having Non Compliant Standards?
The Repetitive Cycle KDE Devs have constantly Breaking and Fixing the Same things in their Desktop Environment.
The Developers of KDE can hardly Stabilize KDE themselves. Its pretty obvious how Bad KDE is and
Not just, Being Extremely Sensitive of changes outside of it like this, if that is not implying Noncompliance
then Noncompliance is clearly their Standard.This is an immediate affect of Noncompliance.

I think its sad and hysterical to divert to AMD or OpenGL being the problem in this Regard.
These kinds of Issues tend to be Limited to KDE.
This affecting their cursor of all things is Stupidly Hilarious.

Nvidia, holy cow I can believe someone mentioned them.

[smitty3268]

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.

Source?

I find it hard to believe that AMD made their drivers non-compliant with OpenGL 4.6 knowingly. If they don't pass conformance tests, don't they legally have to stop saying their drivers are OpenGL 4.6 compliant?

The gl threading is supposed to be transparent to applications, and provide the same behavior. Obviously bugs can exist and OpenGL may not be 100% defined in certain areas that may end up changed, but claiming it's non-compliant and fails tests is pretty bold.

[ATFx]

True this is hardly a Fix, Disabling it for Instead of Reverting Sacrificing Driver Progress for an inherently Buggy Application is just the Wrong Approach to the issue
If KDE Devs care enough they'll fix their Incredibly Sensitive Out of Standard Programming in their Desktop Environment,
that makes something as basic as making OpenGL multi threaded to an Existing OpenGL Function affect their Cursor.
These issues are unbelievable but consistent in their flawedness.

[abott]

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).

What a bunch of BS. I've been using it since it was introduced YEARS ago, and there were more issues at first, but you can't test the shit you need to unless you get a number of people using it. It's not broken you imbecile, it has a couple bugs with a couple of (probably) buggy programs and they're getting ironed out. If it's SO broken, I'd like to see your patches to fix it. And I'd also like to see your bug report where you just so happened to run across this exact issue.

In basic programming, I learned (with experience)

You didn't learn enough to comment on this. Your reply is like a "basic computing 098" class and this is more like "3d graphics engineering 590" if this were a subject. You're not wrong, but you are obviously WAY off your rocker calling this for not being perfect.

Unless the bugs get reported, and these didn't for MULTIPLE. YEARS. Then they can't get fixed. It's literally that simple. If you hate it so much, patch it up or get over it.

[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.

[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]

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.

[middy]

why does this affect wayland kwin and not x11 kwin?

[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.