GNOME's Mutter Begins Landing Transactional KMS Support

[phoronix]

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?page=news_item&px=GNOME-Transactional-KMS

[q2dg]

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

[shmerl]

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

[andrei_me]

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

[Michael]

See the Enlightenment views on it when they started using the new APIs: https://www.phoronix.com/scan.php?pa...Atomic-Nuclear

[q2dg]

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!

[hax0r]

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

[shmerl]

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?