Announcement

Collapse
No announcement yet.

Vulkan Wayland Compositors Are Nearing Reality

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

  • #31
    To all those who replied, thank you very much!
    So it seems it does really boil down to resolutions we use these days.
    I did bump into this old post when looking for some information https://www.phoronix.com/scan.php?pa...D-Acceleration

    So when i say 'fastest path'. I'm talking about the fact that there is a delay with the system offloading to the gpu. At least, there used to be. This isn't in the 'games' use case, obviously you need to offload it then. But 2d cpu / 2d accel was always better for a snappy responsive desktop.

    Comment


    • #32
      Originally posted by iskra32 View Post

      A lot of it has to do with power consumption. Sure, maybe a barebones compositor can maintain 60fps, but don't expect it to run particularly efficiently or be able to have any kind of advanced featureset. And then as you open up more applications that'll slow it down even more. There are tricks that one can use to reduce input latency to something completely imperceptible on a GPU accelerated system
      That's interesting. I would be interested in the 'tricks to reduce input latency'. Any pointers?

      Thanks for the reply!

      Comment


      • #33
        Originally posted by polarathene View Post

        SNIP

        TL;DR

        CPU is not the fastest path, GPUs are great at manipulating a lot of pixels and 3D is generally broken down into many triangles, those can still be arranged into shapes for 2D usage where the 3rd dimension is depth for layers (eg windows over other windows, context menus, etc).
        Well, that was a wonderful amount of info. Thanks for all that!

        Comment


        • #34
          Originally posted by intelfx View Post

          Because CPU is not a fastest path anymore. Count pixels on a 4K screen, then multiply by bpp, then multiply by some fixed factor to account for multiple layers of textures in compositing, and then compare that with RAM throughput and CPU frequency*IPC. You'll be surprised.

          TL;DR: yes, we've been doing this for years. If you are content with a single 1024x768 display with windows drawn in immediate mode (so basically no protection against unresponsive apps), feel free to continue to do that. But copying huge blocks of pixels back and forth is literally the worst possible use of CPU time and RAM bandwidth.
          Fantastic. Cheers!

          Comment


          • #35
            Originally posted by bofh80 View Post

            That's interesting. I would be interested in the 'tricks to reduce input latency'. Any pointers?

            Thanks for the reply!
            I'm not the person you're replying to, but for one you can use repaint scheduling to delay compositing until just before vblank, so that the image is as up to date as possible while still vsynced. wlroots and weston already do this (with a static delay) and mutter is also working on it. You can also use hardware planes to effectively offload compositing to hardware, avoiding copying and compositing latency. A good example of this is the cursor plane - notice how the cursor never suffers from compositing latency.

            Here's a good article on the topic: https://raphlinus.github.io/ui/graph...r-is-evil.html

            Comment


            • #36
              Originally posted by bofh80 View Post

              That's interesting. I would be interested in the 'tricks to reduce input latency'. Any pointers?

              Thanks for the reply!
              I am not certain how other compositors do it, but Kwin(once 5.21 releases of course) for example estimates how long compositing will take based on past frames, and then does it just in time before a vblank. This means that hypothetically there shouldn't be *any* latency beyond the usual(and unavoidable due to how displays work) delay between frames.

              Comment


              • #37
                Originally posted by bofh80 View Post
                while, that's nice. n all. great work. kudos all around.
                however, would someone put me out of my misery and tell me WHY we need 3d for desktop?
                What's wrong with the fastest path, cpu? like we've been doing for years. (with or without buggy 2d accel).
                And i don't mean the software emulated compositor. . Unless you're going to tell me it's as fast and responsive as.
                Is it just the resolutions we use these days or what?
                (I don't care for stupid fancy effects, i'm looking for some technical reasons beyond eye candy)

                Considering that most of you are using a composited desktop i expect a lot of considered responses.
                Actually the main benefits have little to do with being 3D and more
                • Vuilkan was designed with multi threading/parallelism in mind which means it will make it easier to do smoother/responsive compositing by delegating work on multiple threads
                • Vulkan is a lot lower level than OpenGL which ultimately gives more control to programmers allowing them to squeeze more performance
                My response is assuming we are making a comparison to OpenGL on a GPU, if we are dealing with CPU compositing than Vulkan will be much much faster and responsive

                Comment


                • #38
                  Originally posted by mihau View Post

                  I'm not the person you're replying to, but for one you can use repaint scheduling to delay compositing until just before vblank, so that the image is as up to date as possible while still vsynced. wlroots and weston already do this (with a static delay) and mutter is also working on it. You can also use hardware planes to effectively offload compositing to hardware, avoiding copying and compositing latency. A good example of this is the cursor plane - notice how the cursor never suffers from compositing latency.

                  Here's a good article on the topic: https://raphlinus.github.io/ui/graph...r-is-evil.html
                  Oh that's great too, i'm reading it through it. I noticed this :
                  http://www.lofibucket.com/articles/dwm_latency.html
                  I feel less alone

                  Comment


                  • #39
                    Originally posted by mdedetrich View Post

                    Actually the main benefits have little to do with being 3D and more
                    • Vuilkan was designed with multi threading/parallelism in mind which means it will make it easier to do smoother/responsive compositing by delegating work on multiple threads
                    • Vulkan is a lot lower level than OpenGL which ultimately gives more control to programmers allowing them to squeeze more performance
                    My response is assuming we are making a comparison to OpenGL on a GPU, if we are dealing with CPU compositing than Vulkan will be much much faster and responsive
                    Good news. It would be rather interesting to try the new compositors on vulkan, as you say, it might resolve a lot of 'perceived' issues. Cheers!

                    Comment


                    • #40
                      On top: Vulkan has a CPU-only implementation "Lavapipe" (Phoronix article).

                      While this might create an additional overhead it should make even the weirdest platform (with or without a GPU at all) Vulkan-compatible and thus - makes every Vulkan-based application (e.g. here: compositors) available to the user.

                      Even the ones who bought into nvidia will have this absolute fallback available to them, no matter what.

                      Disclaimer: that is, if I understood their project correctly


                      Edit:
                      Holy Moly, it actually works - spinning cubes!
                      Code:
                      $ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json vkcube 
                      WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
                      Oh yeah, and Quake of course: https://www.youtube.com/watch?v=Goed4wr2jf4
                      Last edited by reba; 21 January 2021, 03:34 PM.

                      Comment

                      Working...
                      X