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

[oiaohm]

If it's not thread safe to do, then the driver shouldn't do it. That's the whole idea here. DOH. And that fence doesn't mean shit if it's never used or optimized out, which is an option in the pipeline. NON-ISSUES.

Non thread safe behavior is part of the opengl standard. So driver don't do it the function that way the driver is non conformant. Never used would be ideal but when working on hardware that does not support opengl 3.2 as some embedded systems kde implementation has attempted to support the newer multi thread safe functions are not there. Optimized out again is not option.

Correctly placed fences and alternative code paths both require application modifications not driver. This is just a case opengl is down right old with lots of legacy crud.

Opengl driver developers are seriously between rock and hard place due to the Opengl standard.

[abott]

Some opengl functions are not thread safe.
https://github.com/RPCS3/rpcs3/commi...4f19375c05c67d
This leads to work arounds like above adding fences.

If it's not thread safe to do, then the driver shouldn't do it. That's the whole idea here. DOH. And that fence doesn't mean shit if it's never used or optimized out, which is an option in the pipeline. NON-ISSUES.

[piotrj3]

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.

This is more due to poor synchronization aspect of Wayland. Generally speaking, in Wayland you might often face situation of sort, hey i have complex blender scene that will of course lag, but because it is lagging it brings lag on entire desktop. Mouse also is rendered this way (by default) and you have those sort of issues.

There is some proposals to fix it ( one by nvidia employee) some involve explicit sync some involve hacks on implicit sync.

[oiaohm]

I'm quoting your moronic bullshit that says OpenGL threading is defacto broken. It's not. The driver has bugs, but the threading is GENERALLY stable. It's issues are to be ironed out in the driver ONLY. Valid OpenGL should ALWAYS work. If it doesn't, it's a bug, and threading triggering bugs elsewhere means absolutely fuck all about KDE's issues. KDE is either hitting someone else's bug, or their own, but if it's their own, it was ALWAYS broken.

Vulkan isn't what's being talked about. The concurrency issues are a non-issue when your code/driver isn't bugged. Vulkan is much better at it, but your claims about OpenGL generally being fucked with threading are COMPLETELY incorrect, provided it worked as it should. They've got other issues, yes, but they're not anything to do with OpenGL's spec. The OpenGL spec should be followed, and that's the rule. If it breaks the rules, the driver is to blame.

The catch the opengl covers a very long time frame. Early opengl there is no idea of multi threaded because the systems it was being developed on you had a single thread for drawing that was it. VBO and other parts appear after 1.4 opengl as addons to opengl and in specification at opengl 3.2 that allow multi threaded functionality with opengl with reasonable safety.

Some opengl functions are not thread safe.
https://github.com/RPCS3/rpcs3/commi...4f19375c05c67d
This leads to work arounds like above adding fences.

Abott opengl threading is more case works due to applications altering their code bases adding extra functions that you don't need for single threaded opengl. Yes the specification of opengl is written that everything will be done in order by the way as in single threaded. Those implementing opengl take the directive in the opengl standard that it should be single threaded as only a guideline.

The fact how opengl handles threading it not clearly written in the opengl standard is what leaded to Vulkan.

There are tones of examples of applications that work with opengl threading enabled but these applications are really using a subset of Opengl and obeying particular rules on how to do things like including fences.

[abott]

What are you on about?

I'm quoting your moronic bullshit that says OpenGL threading is defacto broken. It's not. The driver has bugs, but the threading is GENERALLY stable. It's issues are to be ironed out in the driver ONLY. Valid OpenGL should ALWAYS work. If it doesn't, it's a bug, and threading triggering bugs elsewhere means absolutely fuck all about KDE's issues. KDE is either hitting someone else's bug, or their own, but if it's their own, it was ALWAYS broken.

Vulkan isn't what's being talked about. The concurrency issues are a non-issue when your code/driver isn't bugged. Vulkan is much better at it, but your claims about OpenGL generally being fucked with threading are COMPLETELY incorrect, provided it worked as it should. They've got other issues, yes, but they're not anything to do with OpenGL's spec. The OpenGL spec should be followed, and that's the rule. If it breaks the rules, the driver is to blame.

[oiaohm]

First off, that initial link isn't even talking about internal driver threading. It's discussing how apps can use threading external to the driver, and basically says you can. But nothing in there applies to the internal threading the driver does, because all that is hidden from the user application.

Except what you just wrote is absolutely not true that it is hidden. mesa_glthread=false and mesa_glthread=true produce different results at the application level
https://gitlab.freedesktop.org/mesa/mesa/-/issues/2965
Multi different reports show that its not hidden from the application, Yes this is another bug that the application changed the code to cover for the difference in behavior between the two modes and then the bug was closed. Mesa has not been fixed for many mesa_glthread=false vs mesa_glthread=true differences that are visible to the application level. Yes these are corner cases in the way opengl is used.

And as for the fact that certain GL calls don't work with threading, well, yeah. Obviously. That's why mesa's gl threading code doesn't use threading for those api calls. It only does it for the ones that do work. That's the entire point of how it's designed, and barriers are setup so that sync calls will cause everything to work in the proper order and succeed.

Next those barriers don't magically exist.
https://download.nvidia.com/develope...-Practices.pdf
As noted in 2006 to use vertex arrays safely with thread opengl you need to use vertex buffer objects. That is not part of opengl core until 3.2 yes it was optional ARB in 1.4 opengl.

What you get wrong here is once you see one function that not for threading. You need to stop threading processing straight away. Shaders and other things can be built expecting single threaded behavior.

https://github.com/RPCS3/rpcs3/commi...4f19375c05c67d
That bug 2965 the application adds it own synchronization fence to the application code. There are many cases where Mesa3d is unable to correctly added the barriers with mesa_glthread=true if the application does not do this it self. Yet this can be code that worked perfectly fine on all opengl implementations without threading in the driver.

Yes certain GL calls don't work with threading you are right mesa does not thread those. There is problem Mesa3D does not respond to seeing application using those functions with set mesa_glthread=false. Opengl application using functions that are not thread safe means application will not have synchronization fences and the like to make sure everything is is processed in the correct order. There is bug report after bug report with this happen with mesa. Yes all those bug reports end up closed when the application alters it code never fixing the Mesa issue.

So given your history I fully expect you to respond to this post with another wall of text full of further nonsense that either has nothing to do with the topic, or full of misunderstandings where you think you know stuff you clearly don't. But I'm done, this is my final word on the topic because it's not worth reading your posts anymore.

I see you want to respond with garbage that is not true and blame it on me writing wall of text. The reality your answer has a core mistake the idea that Internal mesa threaded operation does not not show through to the application the reality it does. This is why RPCS3 and many others have had to alter their code bases so they work with mesa in threaded mode.

[smitty3268]

https://www.khronos.org/opengl/wiki/...multithreading
...
...
...

Ok, I went to the trouble of reading that whole wall of text you wrote, and now I regret it. Because it's utter nonsense.

First off, that initial link isn't even talking about internal driver threading. It's discussing how apps can use threading external to the driver, and basically says you can. But nothing in there applies to the internal threading the driver does, because all that is hidden from the user application.

And as for the fact that certain GL calls don't work with threading, well, yeah. Obviously. That's why mesa's gl threading code doesn't use threading for those api calls. It only does it for the ones that do work. That's the entire point of how it's designed, and barriers are setup so that sync calls will cause everything to work in the proper order and succeed.

So given your history I fully expect you to respond to this post with another wall of text full of further nonsense that either has nothing to do with the topic, or full of misunderstandings where you think you know stuff you clearly don't. But I'm done, this is my final word on the topic because it's not worth reading your posts anymore.

[Quackdoc]

Eh? Before I moved my displays to the iGPU to save idle power, I was running KDE Wayland on Polaris and it was working just fine as far as I could tell.

im talking about vulkan support specifically, wlroots (sway wayfre etc.) has vulkan support but requires that VK extension that polaris doesn't support

[yump]

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 think there are two separate issues. One is that on a VRR display some single app is given control of the refresh timing (which is the entire point), and so no matter how or when the cursor plane is moved, it can't be scanned out more frequently than the VRR refresh timing as dictated by the app. The problem occurs when apps retain control of the refresh when they shouldn't, either when they are minimized and not visible, or when they are rendering too slowly and the compositor should switch into a frame-doubling mode (which would then update the cursor at 2x the app frame rate).

Issue two, which is what the link is about, is that hardware cursor plane movements are delayed to the next vsync pulse, because of the design of the atomic KMS API, which is possibly a consequence of boneheaded "every frame is sacred" wayland ideology.

[shmerl]

Vulkan limits you to GPUs not older than ten years or so, and there are probably a lot of those that people want to be able to use for machines that have no need for 3D acceleration but require a graphical desktop. And the cutoff might be more recent for ultra-low-end "video output only" cards, since those tend to use recycled architectures.

I have no problem with that. Tax of supporting ancient GPUs is a dubious trade off. Besides, OpenGL support can be kept around as a fallback, until they decide enough time was given for it.