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

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

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

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

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.

[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

[smitty3268]

KDE. This Article.

KDE having a bug doesn't mean the drivers are non-compliant. It just means KDE has a bug.

Also, oiaohm was very clear about saying Khronos Group conformance tests were failing, which is what I was specifically responding to. Not random apps.

[Alexmitter]

I wish KDE would use Vulkan instead of OpenGL.

If KDE already struggles this much with OpenGL, I would not even let them near Vulkan.

[mdedetrich]

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.

What are you on about?

If KDE already struggles this much with OpenGL, I would not even let them near Vulkan.

Vulkan doesn't have these issues because concurrency is largely explicit, it was designed right from first release to handle multi threading in mind. Its not that KDE alone has issues with multiple threads in OpenGL, almost everyone does (to the point where was stated previously pretty much almost game did single threaded rendering in GL).

So yeah ignoring your sensationalist bullshit, if KDE hypothetically used Vulkan they wouldn't even have this problem.

[Alexmitter]

It's designed to stutter even with hardware cursor.
If you want non-stuttering cursor, you will have tearing.
https://github.com/swaywm/sway/issue...ment-578462619

I am not sure if you understood the problem. This is a consequence of the DRM atomic interface syncing all the planes.
Your wayland shell should never drop frames or slow down just because a client slows down, and because of that the cursor should also not slow down.

[d3coder]

I am not sure if you understood the problem. This is a consequence of the DRM atomic interface syncing all the planes.
Your wayland shell should never drop frames or slow down just because a client slows down, and because of that the cursor should also not slow down.

I am not wayland developer, I don't care about the details. I just know that all wayland compositors are affected and Xorg does not have this problem.