Announcement

Collapse
No announcement yet.

RadeonSI Adds EGL Context High Priority Support To Help Wayland Compositors

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

  • RadeonSI Adds EGL Context High Priority Support To Help Wayland Compositors

    Phoronix: RadeonSI Adds EGL Context High Priority Support To Help Wayland Compositors

    Landing today in the RadeonSI Gallium3D driver code-base for Mesa 22.2 is support for the EGL_IMG_context_priority extension. The RadeonSI EGL_IMG_context_priority support was contributed by a KDE developer with the motivation of ensuring Wayland compositors can have high priority for rendering...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Michael The answer I got from the KwinFT project for supporting this extension probably deserves its own news entry as the future of that project is in question.

    Comment


    • #3
      Originally posted by ms178 View Post
      Michael The answer I got from the KwinFT project for supporting this extension probably deserves its own news entry as the future of that project is in question.
      Yeah. I said that in KDE thread. Funny that weeks before Steam deck release we were wondering if whether it's gonna use kwinft. And now we're already mourning it. I wish Valve could hire Roman for work on kwinft since they already have interest in KDE and wlroots.

      Comment


      • #4
        Originally posted by RejectModernity View Post

        I wish Valve could hire Roman for work on kwinft since they already have interest in KDE and wlroots.
        I heard somewhere that Valve funded his work on KwinFT. Is that not the case anymore?

        Comment


        • #5
          As Roman talks about this openly in the comment in the linked MR, his funding seems to have dried up. From Valve's point of view I can understand that decision to some degree as they want to consolidate their investment on upstream KDE. It seems that Roman wants to partly keep working on his project albeit with less time to spend. With all the breaking changes now and then in wlroots and other maintenance work, I don't know if that is practical in the long run. I hope he can elaborate on his thoughts in a blog post. Maybe some other company finds KwinFT worthwile to keep going at full speed...
          Last edited by ms178; 25 May 2022, 05:56 PM.

          Comment


          • #6
            I wonder whether things like these should really be done as part of DRM where you can maybe have GPU 'niceness' associated with a process. The issue with EGL extensions like this is that if someone is writing a Vulkan compositor (like gamescope), they won't be able to do something like this
            Last edited by SethDusek; 26 May 2022, 12:46 AM.

            Comment


            • #7
              As a KDE Plasma and AMD GPU user this is great!

              But I wish somthing like this would work on Intel iGPU too.
              KDE Plasma seems slow or not snappy enough on Intel iGPU, especially on Wayland.

              Comment


              • #8
                Originally posted by ms178 View Post
                Michael The answer I got from the KwinFT project for supporting this extension probably deserves its own news entry as the future of that project is in question.
                My personal opinion is that KwinFT was a failure, because the author didn't manage to get it upstream. Correct me if I'm wrong but as far as I know, upstream is now already solving the same problems in a different way.

                Or am I missing something?

                Comment


                • #9
                  Originally posted by Venemo View Post

                  My personal opinion is that KwinFT was a failure, because the author didn't manage to get it upstream. Correct me if I'm wrong but as far as I know, upstream is now already solving the same problems in a different way.

                  Or am I missing something?
                  AFAIK, KwinFT was never intended to be upstreamed to replace the current upstream Kwin. The dev behind KwinFT was formerly an upstream KDE dev and he left because he didn't like the development practices of KDE. From reading his blogposts I understand that with KwinFT he wants to make some fundamental rewrites of the compositor that will have some long term benefits compared to upstream Kwin.

                  Comment


                  • #10
                    Originally posted by Venemo View Post

                    My personal opinion is that KwinFT was a failure, because the author didn't manage to get it upstream. Correct me if I'm wrong but as far as I know, upstream is now already solving the same problems in a different way.

                    Or am I missing something?
                    I think you are missing that Roman tried his best to work with other upstream KWin developers to improve the status of KWin back at the beginning of his funding but met stiff resistance for some of his ideas for more radical changes in the code base. Upstream KWin is catching up only now to tackle some of these deeper underlying problems which Roman pointed out from the beginning of his work, they now duplicate some effort.

                    I would not call KwinFT a failure, at least not technologically. But I cannot comprehend why both sides failed to cooperate and coordinate their work more closely, they should have left their personal differences aside and could have agreed upon to support such an experimental out-of-tree project with the goal to assess its potential at some point in time, either merging the good parts back into the upstream project or to use KwinFT as the basis for a more moden KWin successor at one point in the future. That hasn't happened yet, unfortunately.

                    Comment

                    Working...
                    X