Announcement

Collapse
No announcement yet.

GNOME's Mutter Begins Landing Transactional KMS Support

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

  • GNOME's Mutter Begins Landing Transactional KMS Support

    Phoronix: GNOME's Mutter Begins Landing Transactional KMS Support

    Adding to the excitement of GNOME 3.34 and the many changes being worked on is Mutter seeing the initial merging of transactional kernel mode-setting (KMS) support...

    http://www.phoronix.com/scan.php?pag...nsactional-KMS

  • #2
    This! Almost as exciting as the sysprof integration. Now they just need to merge the picking optimizations. 2019 is awesome.

    Comment


    • #3
      Sorry for the silly question but...why may this be useful? Thanks!

      Comment


      • #4
        Yeah, what exactly are the practical benefits (besides thread offloading)?

        Comment


        • #5
          Originally posted by q2dg View Post
          Sorry for the silly question but...why may this be useful? Thanks!
          AFAIK, changing resolution/plugging another display/things related to display events would happen in one-shot, without flickering, and the atomic API tests the change before applying it, so if the change would fail, it won't happen with the flickering in the screen

          Comment


          • #6
            See the Enlightenment views on it when they started using the new APIs: https://www.phoronix.com/scan.php?pa...Atomic-Nuclear
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by andrei_me View Post

              AFAIK, changing resolution/plugging another display/things related to display events would happen in one-shot, without flickering, and the atomic API tests the change before applying it, so if the change would fail, it won't happen with the flickering in the screen
              Ah, ok, understood. Thanks a lot!

              Comment


              • #8
                Originally posted by shmerl View Post
                Yeah, what exactly are the practical benefits (besides thread offloading)?
                Think of gfx card and the features it provides that are built right into the silicon: Framebuffer, HW Cursor, and Planes (beside goodies like 2D and 3D engines). Back in early 90s a framebuffer was considered a luxury. A Plane (aka "overlay") for example can be an image source that's blended/overlayed on top of CRTC during scanout process without need of CPU cycles. Not all HW provides it--just like in HW cursor, if not available the rendering process will resort to sw blending via cpu or gpu. Usually a GPU will contain at least 3 Planes (1st plane/overly usually is DE e.g. mutter, 2nd is hw cursor, 3rd may be YUV video)

                DRM Atomic modesetting, among things allows userspace to use 'overlay planes' and bypass compositor leading to much decreased memory bandwithd, higher FPS, and lower power usage. It is one of the more exciting aspects of DRM subsystem.
                - prior to it, there was no interface to update multiple planes together, had to use like 3 ioctls and pray it would happen in same frame
                - it was a showstopper for Wayland compositor, since it needed pixel-perfect updates for every frame
                - with 'overlay planes' you can bypass compositor and ease the GPU load!!!

                Btw CRTC is term that still lingers around to these days and comes from CRT era, at least in Linux DRM subsystem codebase a CRTC is a pointer to scanout buffer; CRTC struct contains:
                • pointer to frambuffer
                • list of driven connectors
                • display mode (modeline and resolution; aka pixel clock in LCD age)
                • various x/y offsets

                Comment


                • #9
                  Originally posted by hax0r View Post
                  DRM Atomic modesetting, among things allows userspace to use 'overlay planes' and bypass compositor leading to much decreased memory bandwithd, higher FPS, and lower power usage. It is one of the more exciting aspects of DRM subsystem.
                  - prior to it, there was no interface to update multiple planes together, had to use like 3 ioctls and pray it would happen in same frame
                  - it was a showstopper for Wayland compositor, since it needed pixel-perfect updates for every frame
                  - with 'overlay planes' you can bypass compositor and ease the GPU load!!!
                  Thanks for the explanation and details! Are all compositors planning on using these features?

                  Comment

                  Working...
                  X