GPU

The CentOS kernel modules "Kmods" special interest group (SIG) is now providing NVIDIA Linux Open GPU Kernel Modules for users of Red Hat Enterprise Linux and its downstreams as well as for CentOS Stream.

The CentOS Kmods SIG has begun providing kernel module builds for the open-source NVIDIA Linux Open GPU code that is the official NVIDIA Linux kernel drivers that are part of their driver package and maintained out-of-tree from the Linux kernel. The Kmos SIG is tracking NVIDIA's latest feature branches and making them installable via the "kmod-nvidia-open" package name as well as of the production branches like R570 with "kmod-nvidia-open-570". There are also supported Long Term Support / Legacy branches like "kmod-nvidia-535" for those needing legacy GPU driver support.

Last week I provided a look at how Intel's GPU compute performance on Battlemage evolved in 2025. In today's article is a similar Intel Arc A-Series "Alchemist" and B-Series "Battlemage" look at how the OpenGL and Vulkan graphics performance has evolved over the past year. Simply put, the open-source Intel Linux graphics driver stack has evolved immensely this year... Not just for Vulkan but even the OpenGL support continues moving in the right direction too.

In addition to Intel Arrow Lake desktop performance evolving nicely on Linux over the course of 2025, the Intel Arc B-Series graphics that launched last December with the Arc B580 have evolved quite nicely too with their open-source driver stack. With it coming up on one year since the Arc B580 launch, here is a look at how the GPU compute performance has evolved since that point. Similar Intel Arc B580 Linux graphics comparisons are also coming up in a follow-up comparison on Phoronix

Initially upstreamed into the Linux 6.18 kernel is Tyr as a Rust-based GPU kernel driver for Arm Mali hardware. This is in effect a Rust alternative to the Panthor DRM kernel driver for newer Arm Mali GPUs with the Command Stream Firmware (CSF). With the latest development code for Tyr, it's moved onto running the GNOME desktop and basic games like SuperTuxKart.

NVIDIA engineers continue working a lot on the open-source and upstream Nova driver for the Linux kernel. This modern, Rust-written open-source NVIDIA driver is still taking shape as an alternative to NVIDIA's official downstream open-source driver and the aging and reverse-engineered Nouveau driver. Out on the horizon for Nova is Hopper and Blackwell GPU support.

NVIDIA engineer John Hubbard is in the process of preparing Hopper and Blackwell GPU generations for being supported by the Nova driver. Another NVIDIA engineer is working on the Turing GPU support. Nova as a reminder is just engineered for recent generations of NVIDIA GPUs supporting the GPU System Processor (GSP)

NVIDIA is taking the open-source and upstream "Nova" kernel graphics driver quite seriously for their hardware. Hitting the mailing lists on Friday night were initial patches in beginning to make preparations toward "next-gen GPU" support. Digging into the comments, it's indeed for post-Blackwell GPUs.

Catching me by surprise last night was seeing this patch series hit the wire: gpu: nova: add boot42 support for next-gen GPUs. Clearly calling out "next-gen GPUs". NVIDIA engineer John Hubbard then explained in the patch cover letter:

"NVIDIA GPUs are moving away from using NV_PMC_BOOT_0 to contain architecture and revision details, and will instead use NV_PMC_BOOT_42 in the future. NV_PMC_BOOT_0 will be zeroed out.

Change the selection logic in Nova so that it will claim Turing and later GPUs. This will work for the foreseeable future, without any further code changes here, because all NVIDIA GPUs are considered, from the oldest supported on Linux (NV04), through the future GPUs.

Add some comment documentation to explain, chronologically, how boot0 and boot42 change with the GPU eras, and how that affects the selection logic.

Also, remove a couple of types: Spec and Revision. That deletes a net total of 33 lines of code and simplifies that area of code. It also simplifies the subsequent boot42 support diffs."

Early this year, NVIDIA released their new raytracing technology, RTX Mega Geometry, alongside an impressive Zorah demo. This demo was distributed as a ~100 GB Unreal Engine scene - that can only be opened in a special branch of Unreal Engine, NvRTX. The demo showcased the application of new driver-exposed raytracing features, specifically clustered raytracing, in combination with Nanite clustered LOD pipeline - allowing to stream and display a very highly detailed scene with full raytracing without using the Nanite proxy meshes that Unreal Engine currently generates for raytracing.

As this was too Unreal Engine specific for me, I couldn’t really experiment much with this - but then, in early September, NVIDIA released an update to their vk_lod_clusters open-source sample, that - among other things - featured Zorah scene as a glTF file. Naturally, this piqued my curiosity - and led me to spend a fair amount of time to improve support for hierarchical clustered LOD in meshoptimizer.

Drill deep into a GPU’s architecture and at its heart you will find a large number of SIMD units whose purpose is to read data, perform some vector or scalar ALU (VALU or SALU) operation on i…