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

[FireBurn]

That's a workaround not a fix...

[Quackdoc]

I wish KDE would use Vulkan instead of OpenGL.

and it would be even more nice if it didn't have a hard dependency VK_EXT_image_drm_format_modifier making it unusable on polaris and below.

[binarybanana]

I don't think GL threading in mesa works like most people here seem to understand it. As far as I know it just makes most calls to GL asynchronous so that they return immediately instead of waiting until they are processed. The actual work then happens in a worker thread maintained by mesa itself.

[oiaohm]

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.

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

The problem is mesa_glthread=false enabled run the test suite and pass then your implementation is 4.6 compliant. Being Opengl 4.6 does not mandate multi thread support enabled in the opengl. Also to claim Opengl 4.6 compliant you don't need to pass the complete conformance testsuite.

Also it gets more complicated.

https://www.khronos.org/opengl/wiki/OpenGL_Context#OpenGL_3.2_and_Profiles

Platform Issue (MacOSX): When MacOSX 10.7 introduced support for OpenGL beyond 2.1, they also introduced the core/compatibility dichotomy. However, they did not introduce support for the compatibility profile itself. Instead, MacOSX gives you a choice: core profile for versions 3.2 or higher, or just version 2.1. There is no way to get access to features after 2.1 and still access the Fixed Function Pipeline.

This is MacOS part solution to the problem. Where they split at opengl 2.1. This kind of split is not define on the Linux/Windows implementations. There are particular opengl functions that are not multi thread compatible. Compatibility profiles introduced in OpenGL 3.2 means that Opengl implementation does not have to support every function on the conformance suite in every mode. mesa_glthread is technically in its own compatibility profile. Yes the MacOS implementation with Fixed Function Pipeline only accessible in opengl 2.1 mode did not prevent it from being classes as fully opengl compliant at the time because you could still pass all the test one way or another.

Yes sorting out this multi thread stuff in the opengl standard to be clearly define I would see as a reason for 4.7. Yes this would be particular opengl functions are expected not to work at all if opengl backend is threaded or calling/using those functions must disable opengl backend threading. Basically some formal agreement around how this threading mess is to be handled instead of leaving it up to vendors to do their own unique thing.

The requirements for passing the opengl conformance testsuite to claim particular version of opengl support is nicely up for interpretation. The reality here mesa_glthread=true not passing the complete opengl conformance test suite does not make the mesa opengl implementation non conformant because in mesa_glthread=false it does pass.

Opengl standard not dealing with the multi thread problem is part of what leads to this cursor handling issue.

This is why this problem is more than 1 guilty party. What KDE Wayland did in this case is to what the opengl conformance suite says should work. You want to support embedded platforms that may be opengl 2.1 or before where you don't have FBO and other nice things to make multi thread safe but are always single threaded then you code gets a multi threaded opengl back end you are screwed.

Lot of ways this need KDE Wayland to double up their code for doing particular things. Opengl with X feature do Z and if X feature is not their do Y. This also applies to the KDE compositor with X11.

This case is the Opengl standard + mesa3d + kde developers are all guilty of causing this problem by different actions.
1) Opengl Standard does not clearly define what functions should be usable in the multi threaded case. Also opengl standard to pass for conformance you can set what ever switches you like to get the test to pass. As long as some setting passes you are conformant.
2) Mesa3d turning glthread on by default and this does not have disable particular list of functions that are not going to work so crash the application or if application uses these functions auto disable glthread because once those functions are used threading is no longer safe(yes this means mesa3d would have to have code to turn off threading support on the fly on a per application base).
3) KDE compositor developers attempting to do a single set of code for everything from early Opengl to Current. The introduction of PBO was quite a big change to opengl and this is what enables multi threading safely if application use it..

In a lot of ways there valid case for a opengl 4.7 without any new Opengl functions but with new defines for multi threading handling that opengl implementations have to pass to claim 4.7 so finally fixing this lack of standard defined handling.

[yump]

I wish KDE would use Vulkan instead of OpenGL.

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.

and it would be even more nice if it didn't have a hard dependency VK_EXT_image_drm_format_modifier making it unusable on polaris and below.

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.

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

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

[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

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

[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/developer/presentations/2006/gdc/2006-GDC-NV_Multi-Thread-Best-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/commit/ebbf329b6aea41a42daf96902b4f19375c05c67d

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.