Linux

Beyond the usual new wired/wireless network hardware support and the other routine churn in the big Linux networking subsystem, the Linux 6.8 kernel is bringing some key improvements to the core networking code that can yield up to a ~40% improvement for TCP performance when encountering many concurrent network connections.

First up, there's been an analysis and reorganization of core networking structures. This effort has been around optimizing cacheline consumption and adding safeguards to ensure future changes don't regress. In turn this optimizing of core networking structures is causing TCP performance with many concurrent connections to increase by as much as 40% or more!

As anticipated Linus Torvalds went ahead and just released the Linux 6.7 kernel as the first new version of 2024.

Following the one week delay to avoid a New Year's Eve release, Linus Torvalds christened Linux 6.7 a few minutes ago. It's now released for those that roll your own kernel builds.

Linus wrote in the brief 6.7 announcement:

"6.7 is (in number of commits: over 17k non-merge commits with 1k+ merges) one of the largest kernel releases we've ever had, but the extra rc8 week was purely due to timing with the holidays, not about any difficulties with the larger release.

The main changes this last week were a few DRM updates (mainly fixes for new hw enablement in this version - both amd and nouveau), some more bcachefs fixes (and bcachefs is obviously new to 6.7 and one of the reasons for the large number of commits), and then a few random driver updates. And a smattering of minor noise elsewhere."

Linux 6.7 has many exciting features including initial support for the Bcachefs file-system, Intel Meteor Lake graphics are stable as is the rest of the MTL platform support, initial NVIDIA GSP firmware support with the Nouveau driver, retiring of Intel Itanium support, and other new features with Linux 6.7.

Now it's onward to the exciting Linux 6.8 merge window.

One of the limitations of Google Chrome's Wayland support has been the Video Acceleration API (VA-API) not being supported for GPU-based video acceleration as it's directly targeted the libva-x11 library. But with code merged on Friday to Chromium, libva-drm is now used to allow for working VA-API acceleration on X11 or Wayland.

The latest Chrome/Chromium browser code now allows for VA-API to work on the Linux Ozone/Wayland platform. The explicit VA-API X11 library use is now using the DRM library instead so that both Ozone's X11 and Wayland platforms are using the same target. Chrome VA-API Wayland support MR

The Linux VA-API support at large for Google Chrome remains a "best effort" solution but in any event this change is a welcome move for enhancing the Google Chrome web browser with native Wayland support for this common video acceleration API.

See this merge for more information on Chrome's forthcoming Wayland VA-API support.

Similar to the long-worked-on GNOME dynamic triple buffering that is applied when the (most commonly integrated) graphics fall behind schedule in rendering the desktop, a merge request for KDE's KWin compositor has also seen similar work in this area for helping the iGPU catch-up in rendering via a "triple buffering" implementation.

Prolific KWin developer Xaver Hugl opened a merge request overnight that in effect is dynamic triple buffering akin to what Canonical/Ubuntu has worked on the past few years for GNOME. Xaver explained in that pull request:

"When it takes more than one refresh cycle to render a frame, which isn't unheard of with weak integrated GPUs, KWin starts compositing immediately and we may or may not hit the vblank deadline. If it's missed, then the buffer takes a whole refresh cycle of the display to be used, which means the refresh rate drops to half of what it should be - resulting in a less smooth appearance and increased latency.

With this MR, KWin schedules frames so that they can always hit the vblank deadline, and allows a maximum of two frames to be pending at the same time. This means that if the GPU can't keep up, latency will be increased just as much as is needed instead of almost one entire additional frame of latency and the halved refresh rate."

Currently the merge request is considered in draft form as there are some open items around the transitioning between double and triple buffering, whether to also add similar triple buffering for KDE on X.Org, and better handling of render time queries still needs to be wired up.

We'll see where this KWin triple buffering work leads and how soon before it's ready for merging.

Eric Engestrom has issued an on-time bi-weekly point release for the Mesa 3D graphics drivers today principally composed of open-source OpenGL and Vulkan drivers commonly used by the Linux desktop.

Mesa 23.3.2 is a bit on the lighter side, which can be attributed to end-of-year holidays or just Mesa 23.3 overall being in better shape.

Among the bug fixes to arrive in Mesa 23.3.2 are a few driver fixes for RADV / Etnaviv / R600g / Iris / ANV / RadeonSI, continued fixes to the Rusticl OpenCL-on-Rust driver, and other small fixes. Baldur's Gate 3 bad rendering

Of the Intel fixes for this point release is the Vulkan workaround change for Baldur's Gate 3.

The full list of Mesa 23.3.2 changes can be found via today's release announcement.