GPU

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…