Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Alexmitter View Post

    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.

    Comment


    • #32
      That's a workaround not a fix...

      Comment


      • #33
        Originally posted by shmerl View Post
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            Originally posted by smitty3268 View Post
            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/...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/...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.

            Comment


            • #36
              Originally posted by shmerl View Post
              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.

              Originally posted by Quackdoc View Post
              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.​

              Comment


              • #37
                Originally posted by yump View Post

                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.

                Comment


                • #38
                  Originally posted by Alexmitter View Post
                  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.

                  Comment


                  • #39
                    Originally posted by yump View Post

                    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

                    Comment


                    • #40
                      Originally posted by oiaohm View Post
                      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.

                      Comment

                      Working...
                      X