Landing in Mesa 21.1 on Friday was a variable rate shading (VRS) override for the Radeon Vulkan "RADV" driver for providing significant performance boosts by effectively rendering less. This feature is limited to RDNA2 graphics processors while here are some benchmarks on what it means for 4K gaming with the AMD Radeon RX 6000 series graphics cards on Linux.

The Mesa RADV driver has Variable Rate Shading (VRS) support for trading less rendering for higher performance. The driver allows setting an environment variable (RADV_FORCE_VRS) to force-enable the functionality even for games/software not making direct use of Vulkan VRS. A value of 2x2 will reduce the fragment shader invocations per pixel to one per 2x2 pixels as a decent performance boost while not degrading quality too much. For the benchmarking today I tested the RDNA2 graphics cards available with the 2x2 setting compared to no overrides.

• X.Org Server Git Lands Support For Hardware-Accelerated XWayland With NVIDIA - Phoronix

  The NVIDIA-led work to allow XWayland OpenGL and Vulkan acceleration with their proprietary driver has just been merged into X.Org Server Git.

  The XWayland changes needed to allow the NVIDIA proprietary driver to work in an accelerated manner have landed in X.Org Server 1.21 Git. The main change is xwayland: implement pixmap_from_buffers for the eglstream backend that was merged just a few minutes ago.

  Before getting too excited, this support is contingent upon a new NVIDIA proprietary driver release. That much anticipated driver update looks to be the forthcoming NVIDIA 470 Linux driver series.

• Xwayland work for hardware accelerated NVIDIA support has been merged in

  Another exciting moment for fans of Wayland and the future of Linux, especially if you're an NVIDIA user, as the work to provide hardware accelerated rendering for NVIDIA GPUs was merged in for Xwayland. We've been following this work for a while, as an upcoming NVIDIA driver will have the code in for everything to be in place (likely NVIDIA 470).

• mesa 21.0.2

  Hi list,
  
  It's that time again, Mesa 21.0.2 is now available for general
  consumption. This release is the culmination of two weeks of hard work
  from the community. There's lots of good fixes here for basically
  everything in the tree from the compilers, to radv, utils, r600, intel,
  lavapipe, egl, aco, st/mesa, and panfrost.
  
  Cheers,
  Dylan
  

• Mesa 21.0.2 Released With Lavapipe Fixes, Improved AMD L3 Cache Calculation

  Mesa 21.0.2 is out today as the latest bi-weekly point release to the Mesa3D open-source Vulkan/OpenGL drivers.

  Accumulating for Mesa 21.0.2 is the usual random smothering of fixes but with no area dominating the change-log this time around. Mesa 21.0.2 has just a few fixes for the likes of the Radeon and Intel drivers but nothing too exciting there. The other changes include several Lavapipe Vulkan CPU driver fixes, disabling of sparse buffers on GFX7/GFX8 for RadeonSi, Mesa state tracker fixes, and a few EGL fixes too.

• Sparse – Mike Blumenkrantz – Super. Good. Code.

  The great thing about tomorrow is that it never comes.

  Let’s talk about sparse buffers.

  What is a sparse buffer? A sparse buffer is a buffer that is not required to be contiguously or fully backed. This means that a buffer larger than the GPU’s available memory can be created, and only some parts of it are utilized at any given time. Because of the non-resident nature of the backing memory, they can never be mapped, instead needing to go through a staging buffer for any host read/write.

  In a gallium-based driver, provided that an effective implementation for staging buffers exists, sparse buffer implementation goes almost exclusively through the pipe_context::resource_commit hook, which manages residency of a sparse resource’s backing memory, passing a range to change residency for and an on/off switch.

• Wayland Is Driving Fragmentation Around EDID Parsing - A Call To Fix That - Phoronix

  In the open-source world there can even be much fragmentation and multiple implementations around something as central as parsing of EDID blobs for monitor (display) information and that's only been made worse by the growing number of Wayland compositors.

  Currently there is no de facto EDID parsing library for Linux but many different choices and most Wayland compositors rolling their own. The Extended Display Identification Data (EDID) is exposed by the kernel to user-space for offering various metadata around the display. This offers much more information in the standardized structure than what the kernel otherwise normally exposes to user-space and is becoming more important for advanced features like high dynamic range (HDR) and advanced color features that are relevant to compositors and other user-space software. (Heck even to reliably query the monitor(s) model string under Linux for the Phoronix Test Suite for years has meant just parsing the EDID information via sysfs.)

This article will cover a few useful applications that can be used to monitor statistics about AMD GPUs installed in your Linux system. These applications will only work properly and show correct information if you are using open source AMD GPU drivers (typically called AMDGPU drivers). If you have an AMD GPU, most Linux distributions should install and enable open source drivers automatically during OS installation. Since the release of “RX” series GPUs, open source drivers for AMD cards have improved leaps and bounds and now have performance almost at par with proprietary drivers. You should prefer open source drivers for AMD GPUs unless you are facing some hiccups or exceptions.