No announcement yet.

Vulkan Wayland Compositors Are Nearing Reality

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    If only one day i could run sway + vulkan on the desktop, it would be the best ever!!!! Latency under vulkan in wayfire is a lot lower compared to sway which feels sluggish at times.
    Last edited by siyia; 20 January 2021, 11:17 PM.


    • #22
      [QUOTE=bofh80;n1233585]WHY we need 3d for desktop?/QUOTE]

      It's more efficient and faster to use the 3D hardware and software than to use the CPU and traditional framebuffers. Crazy as it sounds, it's less work to have each app, the UI libraries, and the window compositor just shoot stuff over into the 3D stack and 'show it' than it is to ask the CPU to stop and handle what should be on the screen and schlep 32 megabytes over to video memory 60 times a second. If you think all this 3D biz seems inefficient, consider what 2 gigabytes a second of transfers from CPU to GPU would do you the rest of your system.

      The 3D hardware and software needed to render a 4K desktop smoothly is already on 'everything', and it's optimized to hold 'textures' (windows) and blast them out to the display. Why not put it to use lighten the load on the CPU? I'm pretty sure that even if you strapped a Raspberry Pi's GPU to a Core i7, the Raspbery Pi GPU would 'feel' smoother for regular desktop stuff than a 100% 2D/CPU stack. Plus, the -second- you want eye candy like transparency or animation, you're doomed with CPU. Try a macOS instance out in QEMU-KVM if you want to feel how awful that is.


      • #23
        Originally posted by shmerl View Post

        If I remember correctly, Nvidia can't support DMA-BUF ....
        It would appear that you may have forgotten the article from around 50 days ago about nVidia implementing DMA_BUF: although the details were a bit sparse.


        • #24
          Originally posted by shmerl View Post
          So now they won't need GBM and EGLstreams anymore?
          If the system has a GPU that supports Vulkan.


          • #25
            Originally posted by CommunityMember View Post

            It would appear that you may have forgotten the article from around 50 days ago about nVidia implementing DMA_BUF: although the details were a bit sparse.
            I don't think it will fully fix their problem. Those kernel issues weren't resolved because they are about GPL. Unless Nvidia will come up with some even more weird dance around it, but then kernel developers will shoot it down even more strongly than before.


            • #26
              i wonder if vulkan DEs will draw more power from the GPU or will be the same or less of GL.


              • #27
                Originally posted by polarathene View Post

                Even if you're not fond of any eye-candy, depending on DE it would make sense to prefer the more performant choice for such when it comes to supporting those who would like such.

                What's your definition of eye candy though?
                Some day there will be a fiery Michael Bay movie explosion following behind my cursor as it moves across the screen that grows in intensity the further the mouse moves from its initial position. Just wait.


                • #28
                  GBM is a buffer manager, EGLStreams is a generic API to manage buffers but way too limited for Wayland.
                  EGL is a API for applications to create a default context for graphics APIs on a display server.
                  Vulkan or OpenGL/GLES here are mainly in the context of the compositor doing compositing work.

                  GBM will still be needed in the future and Nvidia will in short or longer terms have to adopt it, it is the better solution.


                  • #29
                    Compositor maintainers can add all the stuff they want as long as the OpenGL option remains maintained.

                    As a Nouveau user, it's the only thing I can use.


                    • #30
                      Originally posted by bofh80

                      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: