Mesa 26.2 RC1 Lands With OpenCL 3.1, Fresh Vulkan Extensions and Early AV1 Encode

Mesa developers wrapped up feature additions for the next quarterly update. The project tagged version 26.2.0-rc1 on July 15. This marks the branch point before the stable release expected in early August. Contributors shipped dozens of driver fixes and API extensions. The work touches everything from legacy Radeon chips to the latest Arm Mali silicon.

Eric Engestrom announced the candidate in the official mailing list post. He reminded the community to file blocking bugs against the dedicated milestone. The next candidate follows on July 22. But the real story sits in the release notes that accompany the tag.

OpenCL 3.1 now works across multiple implementations. Rusticl, Asahi, Iris, radeonsi, llvmpipe and Zink all expose the newer profile. That brings cl_khr_subgroup_rotate and related subgroup extensions to a wide set of hardware. Applications that rely on modern compute kernels gain immediate access without extra environment variables or experimental flags. The change simplifies deployment for developers who target heterogeneous compute.

AMD’s RADV driver picked up several production-ready features. Protected memory support arrived for GFX10 and newer chips, including Vega 10 parts. VK_KHR_performance_query works on GFX11. The team also enabled VK_EXT_shader_fma, VK_KHR_maintenance11 and VK_EXT_pipeline_protected_access. These additions tighten parity with Windows drivers and unlock new rendering paths in games and professional tools.

Intel’s ANV Vulkan implementation saw similar attention. Optimizations target both performance and feature coverage. The driver now defaults to VK_EXT_descriptor_heap. It adds VK_KHR_calibrated_timestamps and VK_GOOGLE_display_timing. Early work on H.265 10-bit encode also appears in the cycle, though the final pieces may land closer to final release. Users of Arc graphics cards should notice smoother video pipelines once the code stabilizes.

NVIDIA’s open-source NVK driver continues to mature. Mesh shaders, shader atomic float16 vectors and VK_NV_shader_atomic_float16_vector landed. The team exposed VK_EXT_mesh_shader and VK_NVX_binary_import. Early DLSS experimentation also appears in community builds based on this branch. While not yet declared production ready, the progress shows how quickly the reverse-engineered path catches up to proprietary offerings.

Arm’s Panfrost and PanVK drivers received a new compiler called KRAID. The code improves instruction scheduling for Mali GPUs. Support for the G1-Ultra, G1-Premium and G1-Pro chips arrives at the same time. Several Vulkan extensions round out the picture: VK_EXT_conservative_rasterization, VK_EXT_rasterization_order_attachment_access, VK_EXT_shader_image_atomic_int64 and VK_KHR_compute_shader_derivatives. The cumulative effect gives embedded and laptop users noticeably better graphics compatibility.

PowerVR drivers from Imagination added more than twenty new Vulkan extensions in one go. VK_KHR_workgroup_memory_explicit_layout, VK_KHR_maintenance5, VK_EXT_shader_subgroup_ballot and many others now appear. The breadth of coverage makes the driver far more attractive for developers who need broad API support on low-power silicon.

One of the more surprising additions comes from Microsoft. Engineers upstreamed a prototype AV1 encoder that routes through DirectX 12 and Windows Media Foundation. The roughly 900 lines of code target WSL workloads. The goal remains simple: give Linux applications GPU-accelerated AV1 encode without forcing vendor-specific Linux media APIs. VideoCardz first reported the change on July 8. The piece quotes an earlier Phoronix article that detailed the cross-vendor design. At present the implementation handles only I and P frames. Still, it points to tighter integration between Windows graphics and Linux containers.

Legacy support did not get ignored. Fixes went into the old R600g and R300g drivers for Radeon hardware that many assumed had been abandoned. These patches keep ancient workstations and thin clients functional. The team also cleaned up memory leaks in Zink, etnaviv and Panfrost. NIR compiler bugs that produced NaNs in shaders received attention. The stable 26.1.5 release that shipped the same day back-ported many of these fixes to address game regressions in DOOM: The Dark Ages, Elden Ring and other titles.

Alyssa Rosenzweig contributed 92 commits during the cycle, the highest total. Her work spans Intel, Panfrost and broader compiler improvements. Samuel Pitoiset added key RADV and memory-management patches. The full list of 60 contributors reflects the distributed nature of open graphics development. Companies including AMD, Intel, NVIDIA, Arm, Collabora and Valve all played roles, though individual employer tags rarely appear in the notes.

Performance gains appear uneven but measurable. RADV and ANV optimizations target both CPU overhead and GPU throughput. Rusticl shows better hardware utilization on supported chips. KosmicKrisp, the Vulkan-to-Metal translation layer for Apple hardware, now advertises Vulkan 1.4. Early AMD GFX12.1 support also sits in the tree, though it remains behind experimental flags.

Game studios and cloud providers already test these builds. Valve relies on Mesa for Steam Deck and Proton. Cloud gaming services watch the WSL AV1 work closely. Embedded vendors eye the Panfrost and PowerVR updates for next-generation boards. The breadth of change explains why the release feels larger than a typical quarterly step.

Developers can download the tarball from the Mesa archive or pull the git tag directly. Those who hit blocking issues should open tickets against the 26.2 milestone. The project expects to ship the final 26.2.0 release around August 5 after two more release candidates. In the meantime the code offers a clear view of where Linux 3D graphics heads in the second half of 2026.

Hardware support continues to expand in directions that once seemed improbable. NVIDIA’s open driver, Microsoft’s WSL bridge and Arm’s latest Mali chips all advance in the same snapshot. The pattern repeats every three months. Yet the steady accumulation of extensions, fixes and new hardware paths produces a graphics stack that competes with proprietary solutions on more platforms than ever before.