It's been talked about many times from various parties but so far has remained elusive from the mainline LLVM code-base: a SPIR-V back-end for LLVM that would go from LLVM into this Khronos intermediate representation most notably used by OpenCL and Vulkan drivers. Intel engineers are stepping up and hope to help get a proper SPIR-V back-end upstreamed into LLVM.

There have been various out-of-tree efforts and plans talked about by different companies/developers for having a SPIR-V

GCC compiler patches began appearing this morning for IBM Z "Arch14" as a future architecture extension for their Z mainframe processors. IBM Z Arch14 will likely correlate to IBM z16.

IBM z15 was introduced at the end of 2019 as "Arch13" while today is the first time we are hearing of IBM Z "Arch14" and the first time seeing any code in the GCC open-source compiler referencing it. Short of some re-branding

While Linux 5.12 has many great new features , what you won't find in the mainline kernel is the new "NTFS3" kernel driver developed by Paragon Software for NTFS file-systems. That driver is still coming for a future kernel and has now been sent out a twenty-second time for review.

Last summer was the big surprise of Paragon wanting to upstream their NTFS kernel driver to replace the Linux kernel's existing NTFS driver that is mostly read-only and quite basic. Paragon

The latest " Smart Access Memory " work by the open-source AMD Radeon graphics driver stack is an option for the RADV Vulkan driver to force the "SAM" behavior even if the system is not advertising all the video RAM as visible or even if using APU graphics.

With the RADV Vulkan driver optimizations around Smart Memory Access / Resizable BAR, it has been contingent on all of the vRAM being visible, having discrete/dedicated video memory, and not using the "nosam" override to disable the behavior. But

While SDL2-enabled games/applications can already work on PipeWire-based systems like the forthcoming Fedora Workstation 34 thanks to the PulseAudio compatibility layer, the SDL2 library has merged initial support for interfacing with PipeWire.

Merged on Sunday were various pieces of PipeWire audio support code for the SDL library including the playback/capture sink abilities. SDL2 now has a build time option for enabling PipeWire support as well as for whether to dynamically load it.

PipeWire is the Linux audio/video stream server developed by Red

Of the performance-related changes with Linux 5.12 worth noting is faster AES-NI XTS performance for systems relying upon return trampolines "Retpolines" as part of the CPU's Spectre V2 mitigations. On the Intel side this primarily impacts older CPUs where Retpolines is still used while on the AMD side through Zen 3 the Retpolines is still relied upon, which as shown by these benchmarks is now much better off for AMD Ryzen AES XTS performance as measured by Cryptsetup.

As reported last year, AES-

The Linux kernel source tree following the eventful 5.12 merge window is at 28.81 million lines in the source tree across more than sixty thousand files. The largest in-tree kernel driver continues to be the AMDGPU kernel driver, which in the next kernel release or so should be crossing three million lines.

Linux 5.12's merge window wasn't the biggest in recent time with some 508k lines of code added and 312k lines of code removed

Building off the recent DXVK 1.8 release is a new point release with more performance optimizations, game fixes, and related work to this Direct3D-on-Vulkan translation layer that is extremely popular with Linux gamers.

DXVK 1.8.1 is out as the newest stable release for driving Direct3D 9/10/11 over Vulkan for helping Wine / Proton (Steam Play) Windows games often run incredibly well on Linux. With DXVK 1.8.1 the changes include:

The Radeon ROCm open-source compute documentation has been updated to more clearly spell out what was already implied: their focus is on compute for headless, GUI-less workloads and not OpenCL or compute for conventional desktop applications.

Added last week to the main README file on the ROCm repository is a notice that the AMD ROCm platform is intended as a "compute stack for headless system deployments" and not focused on GUI-based software applications. This doesn't appear to be a change in policy but just making it