AMD CPU improvements like INVLPGB for broadcast TLB invalidation, Zen 5 load latency filtering with perf, AMD P-State driver improvements, initial support for the AMD Versal NET SoC, and more.
Intel
On the Intel side is early work on the kernel-side preparations for Advanced Performance Extensions (APX) and continuing to enhance the Trust Domain Extensions (TDX) support.
CPU
For both Intel and AMD there is also crypto performance improvements like faster CRC code for AVX-512 CPUs and faster AES-CTR with modern x86_64 CPUs.
Graphics
Over on the graphics side there is the very preliminary NOVA driver code merged for the future Rust-written open-source NVIDIA kernel driver. Linux 6.15 also brings Shared Virtual Memory support for the Intel Xe driver, standardized reporting to user-space for hung GPUs, Intel Xe EU stall sampling, AMDGPU support for the OEM i2c interface for RGB lighting and more, and AMD Radeon RX 9070 series fan speed reporting.
Bcachefs
Linux 6.15 also brings many enhancements to the Bcachefs file-system as it works on its “soft frozen” state and working to remove the “experimental” flag from the file-system in the not too distant future.
Other
Some other fun enhancements to Linux 6.15 include IO_uring network zero-copy receive, the new FWCTL subsystem, various Apple driver enhancements, MSEAL protection of system mappings, the new “hugetlb_alloc_threads” option to help boot times on large servers, various kernel scheduler improvements, continued work on Rust programming language abstractions, and landing the Zstd 1.5.7 compression code into the kernel.
It’s being built up starting with the foundations. As I understand it, most of the work so far has been adding support for Rust-written GPU drivers into the kernel. I’d guess that they’re going to look at Nvidia’s open kernel drivers to avoid reverse-engineering everything, but it seems like they’re not just copying it. Unlike both official Nvidia drivers, NOVA will talk with the NVK Vulkan driver in Mesa, not Nvidia’s closed userspace drivers. This will likely make it more compatible with parts of the Linux ecosystem that Nvidia has historically had issues with, like Wayland. Even if they don’t look at the official open driver, NOVA will be a lot simpler than Nouveau, as it only supports GPUs with a GSP, to which Nvidia has moved a lot of the magic that used to be in the kernel driver.
Saves you one extra click
AMD
Intel
CPU
Graphics
Bcachefs
Other
“In a local setup, I was able to saturate a 200G link with a single CPU core, and at netdev conf 0x19 earlier this month, Jamal reported 188Gbit of bandwidth using a single core (no HT, including soft-irq). Safe to say the efficiency is there, as bigger links would be needed to find the per-core limit, and it’s considerably more efficient and faster than the existing devmem solution.”
Thanks for doing this
Is this based on the existing open-source driver (https://github.com/NVIDIA/open-gpu-kernel-modules) or will it be entirely new?
It’s being built up starting with the foundations. As I understand it, most of the work so far has been adding support for Rust-written GPU drivers into the kernel. I’d guess that they’re going to look at Nvidia’s open kernel drivers to avoid reverse-engineering everything, but it seems like they’re not just copying it. Unlike both official Nvidia drivers, NOVA will talk with the NVK Vulkan driver in Mesa, not Nvidia’s closed userspace drivers. This will likely make it more compatible with parts of the Linux ecosystem that Nvidia has historically had issues with, like Wayland. Even if they don’t look at the official open driver, NOVA will be a lot simpler than Nouveau, as it only supports GPUs with a GSP, to which Nvidia has moved a lot of the magic that used to be in the kernel driver.
Rust graphics driver for a GPU which I don’t have? I love how Rust-haters hate it!