Mesa 21.1.0 Is Released With Variable Rate Shading Support For AMD GPUs, Performance Improvements And New Vulkan Extensions
Mesa is a swiss army knife of graphics drivers and libraries that are used to provide graphics functionality on all the major GNU/Linux distributions. Mesa 21.1.0 brings Vulkan Variable Rate Shading support for AMD RX 6000 series GPUs, performance increasing graphics optimizations for the OpenGL and Vulkan drivers for both Intel and AMD GPUs, OpenGL 4.6 support in the Zink OpenGL-to-Vulkan translation layer, shader caching for the Lima driver for ARM Mali GPUs and a lot more.
The GNU/Linux Flatpak version of the "Aurora by Excess" PC scene demo from 2018. One of the core Mesa developers is secretly a key member of the Norwegian PC scene demo group "Excess". The demo uses the Vulkan graphics API, through drivers like the Mesa RADV and ANV drivers for AMD and Intel GPUs, to make the graphics appear.
It is almost certain that you are using the Mesa graphics library to render everything graphical if you are using a GNU/Linux distribution with everything other than a Nvidia graphics card. It provides the Vulkan and OpenGL drivers for Intel and AMD graphics cards on x86-64 hardware and a wide variety of other drivers for non-x86 hardware. The latest release is a big one that is packed with interesting features. You wouldn't know from the release-announcement which, due to time constraints, consisted of:
"Mesa 21.1.0 final is now available! There are a lot of new features, but I unfortunately didn't have time to make a list; I'm sure your favorite news website will pick up the slack."
He probably didn't mean us, but we decided to do that homework assignment anyway.
135 different people from Valve, Google, AMD, Intel, Redhat, Collabora and other corporations contributed to this release. The joint efforts of Valve assets Mike Blumenkrantz, Samuel Pitoiset, Rhys Perry, Connor Abbott and Daniel Schürmann made the Valve corporation the by-far biggest contributor to Mesa 21.1.0. The top 20 contributors by code commits (not lines of code) were:
The above list is just the top 20 contributors, they do not make the 115 other people made code commits less important.
New Vulkan Features
The perhaps most interesting feature in this Mesa release is Variable Rate Shading support for those with the very latest AMD graphics technology. This new Mesa feature depends on hardware support that is only found in the very latest RX 6000 series GPUs from AMD.
Variable Rate Shading is a magic trick that decreases GPU load, thus increasing the frame rate, by doing shader operations in pixels blocks of
2x1 instead of doing them one pixel at a time. This magic trick isn't as magic as it may sound, there is a noticeable visual impact if you do this across the board. The Mesa developers have therefore come up with some trickery that decides when variable rate shading is enabled if the feature, which is optional, is enabled with
RADV_FORCE_VRS=1x2, etc). The goal of their trickery is to boost performance with variable rate shading when it is possible to do so without any very apparent loss of quality while temporarily (or in some games, permanently) disabling the feature when the RADV driver thinks the visual quality is reduced to a point where it would be very apparent. The end-result is that some games get a 30% performance boost all the the time, some get a performance boost some of the time and some games won't see much of a benefit at all. Variable rate shading is not enabled by default and it is still considered to be a somewhat experimental features. You can enable it and try it with the
RADV_FORCE_VRS=value is you have a shiny new AMD RX 6000 series GPU. The hardware support this feature requires is simply not there in older AMD graphics chips, so there will be no such support "back-ported" to older AMD graphics cards.
The Variable Rate Shading was done by Samuel Pitoiset at the behest of the Valve corporation.
The previously introduced Mesa support for a resizable graphics memory bar, or "smart access memory" as AMD likes to market it, can be now force-enabled on seemingly unsupported systems. That does not mean you can force-enable this feature on any old computer like that Athlon II with a Radeon 7850 GPU you may or may not have in your spare bedroom. This feature is only supported by AMD on AMD 5000 series processors sitting on a motherboard with a B550 or a X570 chipset. There are machines, specifically newer ones with Intel motherboards, that can safely use this feature even if Mesa does not identify those (specially non-AMD) machines as being supported. You can now set the special variable
RADV_PERFTEST=sam to make Mesa try to force-enable the resizable graphics memory bar feature in Vulkan games and applications. It may or may not do something depending on what hardware you have available. A brand new graphics card is not required, it can work on older AMD GPUs, but a new CPU and motherboard with SAM support is required.
Both the RADV and ANV Vulkan drivers for AMD and Intel graphics chips have gained support for the
VK_KHR_workgroup_memory_explicit_layout Vulkan extension, which allows shaders to explicitly define the layout of workgroup storage class memory and create aliases between variables from that storage class in a compute shader, and the
VK_KHR_zero_initialize_workgroup_memory extension which allows the use of a null constant initializer on shader workgroup memory variables. The proprietary Nvidia Display Driver for Linux gained support for both of those extensions with the release of version 465.24.02 on April 14th, 2021.
Vulkan Performance Improvements
The AMD RADV driver got 320 code commits since the Mesa 21.0 release in March.
Jason Ekstrand ,
Timur Kristóf ,
Tony Wasserka and
Marek Olšák were among the contributors. The result of those efforts is that the AMD RADV driver now performs about 2% better, and the RADV driver now lists
conformanceVersion = 126.96.36.199 and
Vulkan Compute Performance
The Mesa RADV Vulkan for AMD graphics cards driver finished our RealSR 20 anime girls with questionmarks four seconds faster than Mesa 21.0.1 did while AMDVLK 2021.Q2.2, released slightly more than a week ago, finished the test 9 seconds slower than AMDVLK 2021.Q2.1. There was no change in Mesa RADV performance in the waifu2x-ncnn-vulkan image up-scaling test, it performed about the same. AMDVLK 2021.Q2.2 showed a performance regression in that one as well.
The Mesa RADV Vulkan driver has always been far superior to the AMDVLK driver in compute tasks and that's still the case. Mesa is the obvious choice if you want to do Vulkan compute on an AMD GPU.
OpenGL Performance Improvements
"Most of the arm drivers got a lot of internal work too. as did amd and intel. A lot of Marek Olšák's draw overhead reduction work landed.
It's kind of looking like a harder-better-faster-stronger kind of update more than a bunch of new features"
There is nothing groundbreaking for OpenGL applications in Mesa 21.1.0. There is a 0.5% performance-improvement on AMD box with a dedicated graphics card, mostly thanks to optimizations by Marek Olšák, and a 0.65% performance-improvement on an old Broadwell-powered Intel laptop we use to test the Intel Iris OpenGL driver.
Mesa 21.1 contains a special performance boosting patch for 12th generation Intel graphics chips that was initially submitted by Nanley Chery all the way back in September 2019. The "iris: Support I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC patch can boost OpenGL graphics performance between 3.58% and 18.04% on those newer Intel graphics chips. There is another sort-of performance boosting patch for older Intel chips that disables dynamic VAO fastpath on older 8th and 9th generation Intel graphics chips. That previously introduced optimization was meant to boost performance, and it does on most Intel chips. It turned out that it hurt performance on older chips so it is now only enabled for newer chips benefiting from that optimization.
A total of 78 commits were made to the Intel Iris OpenGL driver and a total of 189 commits were made to the AMD RadeonSI OpenGL driver during this release-cycle.
New OpenGL Features
The Nouveau nvc0 driver (for gm200+) has gained support for
Zink Is Now OpenGL 4.6 Compliant
Zink is a pretty neat technology that lets any graphics system capable of rendering Vulkan run OpenGL applications at a price. You can think of it as DXVK (a translation layer that allows Wine to render DirectX 9-11 with Vulkan) at a graphics stack level.
Mike Blumenkrantz, the top contributor to Mesa 21.1.0, made a long list of commits to the Mesa Zink driver during this release-cycle. He was not alone, Erik "Kusma" Faye-Lund, Adam Jackson, Antonio Caggiano, Bas Nieuwenhuizen, Dave Airlie, Eric Anholt, Hoe Hao Cheng and Michel Zou all contributed to bumping Zink OpenGL compliance from 4.1 to 4.6 in this release. It is now at a state where you can pretty much run any OpenGL game or application on any system with a feature-complete Vulkan driver.
Zink could potentially be very useful hardware vendors and others who would like to have OpenGL available on their shiny new platform without having to develop a specific driver for it, investing in a decent Vulkan driver would be enough now that Zink can provide OpenGL functionality "for free". It is not as free at is may sound, there is a heavy performance-penalty attached to Zink:
74.54% of the performance you get with the RadeonSI OpenGL driver on a AMD graphics card isn't bad, but it is 25.45% less performance than what a native OpenGL driver provides.
You can test Zink by running applications with the
You will also need
DISABLE_MANGOHUD=1 if you use MangoHud because it won't play nice with Zink; you will, in fact, not be able to use Zink if you have MangoHud installed unless you disable it.
"Lavapipe got a ton of work and is now credible enough that we test zink with it in ci. most of the arm drivers got a lot of internal work too. as did amd and intel."
Lavapipe is now Vulkan 1.1 compliant and capable of running most Vulkan games and applications. Rendering on Vulkan graphics on a CPU with Lavapipe is really slow, it is not something that provides an alternative to having a graphics card. It is nevertheless a pretty interesting technology from a purely technical point of view.
Gallium Nine developer Axel Davy managed to squeeze 76 commits into the DirectX 9 Gallium driver. Those include thread submit support and tear-free discard support.
It is possible to use Gallium Nine with Wine using the "Gallium Nine Standalone" library available from github.com/iXit/wine-nine-standalone. Will have to manually install it yourself unless you are using Slackware, Gentoo or Arch. It's not hard, you just have to download and extract the binary package into your
$WINE_PREFIX folder and run a
nine-install.sh script. It doesn't play well with other DX9 add-ons like DXVK, we recommend using a dedicated
$WINE_PREFIX for the DirectX 9 games you want to run with Gallium Nine.
The Mesa Clover OpenCL driver got a lot of improvements from Aaron Watry, Dave Airlie, Edward O'Callaghan, Jérôme Glisse, Karol Herbst, Serge Martin and Vinson Lee. It is still only OpenCL 1.1 compliant - on paper, anyway. The OpenCL features
clEnqueueSVMMigrateMem have been implemented and Clover is well on it's way to being OpenCL 3.0 compliant. Getting it fully OpenCL 2.0 is, of course, something that needs to happen before that - and it's not in this Mesa release. The practical result of the changes to Clover since Mesa 21.0 is a far less usable OpenCL implementation. LuxMark works fine with Clover from Mesa 21.0 as long as you disable the
-d-fast-relaxed-math "optimization". Disabling
-d-fast-relaxed-math is also needed for the AMD ROCm OpenCL implementation.
Clover from Mesa 21.1 rendered a garbled image with 95% "wrong" pixels in the LuxMark 3.1 benchmark. That's a rather unfortunate regression. All the new OpenCL features don't do much good when the end result is a unusable product.
The Mesa Lima driver (docs.mesa3d.org/drivers/lima.html) for
Mali-450, but not
Mali-470, got a big improvement that reduces the apparently previously very long waiting times in GTK applications by a lot.
"GTK doesn’t take 18s any more to display the first frame under Lima, that is my personal highlight in Mesa 21.1.0"
Erico Nunes and Vasily Khoruzhick stood for most of the 26 new commits to the commits to the Lima driver. Eric Anholt contributed a few, Qiang Yu contributed one and Vinson Lee fixed some typographical errors. The most notable commits to Lima were "implement GL_EXT_texture_swizzle", "introduce fs and vs shader cache" and "implement shader disk cache". The two latter should improve performance in games since caches are faster.
Boris Brezillon and Alyssa Rosenzweig, author of "Software freedom isn’t about licenses – it’s about power", contributed a really long list of commits to the Panfrost driver for Mali graphics chips found in many Chromebooks, the Pinebook Pro and other ARM devices. The bullet summary is that those with Mali GPU devices get more features and better performance.
The Road To Mesa 21.2.0
The Mesa developers have already begun developing the next major Mesa version and it could, possibly, have some interesting features.
"21.2 will be a new feature one for my drivers. 21.2 Will be Released With Apple M1 Support.
We merged the initial support on Sunday."
Mesa 21.2 will likey be released with support for the graphics chips on the new ARM based Apple M1 machines. She is a skilled ARM developer who has basically written entire graphics drivers for that platform all by herself, so it is very likely be finished in time. It is not certain, just likely, and there is no way to tell until Mesa 21.2 is released on three months time.
The source for for Mesa 21.1.0 can be acquired from https://mesa.freedesktop.org/archive/mesa-21.1.0.tar.xz and a GnuPG signature file you can use to verify it with
gpg --keyserver-options auto-key-retrieve --verify mesa-21.1.0.tar.xz.sig can be acquired from https://mesa.freedesktop.org/archive/mesa-21.1.0.tar.xz.sig. It is signed by the current Mesa release manager Eric Engestrom using GnuPG key
8D8E31AFC32428A6 (we are certain that that key belongs to him).