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

[phoronix]

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

If you habitually ride Mesa Git for the latest and greatest open-source AMD Radeon graphics driver code and use the KDE Plasma desktop with Wayland, you may have noticed a glitchy cursor recently. Fortunately, that's now fixed up with today's Mesa Git code and ended up stemming from the recent global enabling of Mesa OpenGL threading...

https://www.phoronix.com/news/Mesa-G...d-KWin-Wayland

[Sethox]

It's interesting that a multi-thread process can render a cursor so bad. I mean I get it, the systems the cursor is attached to cannot (or is not constructed) to handle multiple processes.
Though that tells me that the module (simplifying here) that handles the cursor is not checking itself for an exact process it needs to use.

In basic programming, I learned (with experience) that you should have cases where you double check the value for progress to continue (basically an if case that guarantees the case) which in this case is to satisfy the process (if my hypotheses is right), so when it happens you at least solved a case before it even happened. Obviously, case by case for moderation to when to apply the teachings...

[Anux]

Your "if" check can happen before or after another thread altered the value. It's not written in rust or some other thread safe language.

[milkylainen]

Calling it fixed seems like a stretch...

[smirky]

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?

[mirmirmir]

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"

[schmidtbag]

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.

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

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.
But hypothetically, let's say KDE is at fault here: they're highly unlikely to be the only ones to get such an issue. We're lucky KDE is open-source, works with the community, and can make quick adjustments like this. Assuming the program is at fault and not the drivers, we can't depend on them being fixed. While it's not a big deal to just simply disable threading in such situations, we can't depend on that being implemented in every instance where that happens, particularly with closed source stuff (and especially not Windows binaries run through wine/proton). So, what if the driver can be tweaked, where we get threading without the glitches?

[Sethox]

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.
But hypothetically, let's say KDE is at fault here: they're highly unlikely to be the only ones to get such an issue. We're lucky KDE is open-source, works with the community, and can make quick adjustments like this. Assuming the program is at fault and not the drivers, we can't depend on them being fixed. While it's not a big deal to just simply disable threading in such situations, we can't depend on that being implemented in every instance where that happens, particularly with closed source stuff (and especially not Windows binaries run through wine/proton). So, what if the driver can be tweaked, where we get threading without the glitches?

You are right there is no point for pointing fingers since it's just needs to be fixed by Mesa (project outside KDE) that affects KDE.

[Quackdoc]

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

yup these issues are one of the things that finally made me switch to wayfire

[V1tol]

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

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.