Mesa 20.1.5 Is Released With 29 Bug-Fixes And SDMA Disabled On Vega GPUs
The fifth bug-fix release to the stable 20.1 branch of the Mesa graphics library all GNU/Linux machines use to provide 3D capabilities has 29 mostly very small bug-fixes. Only one change will have larger impact: Vega graphics card join the rest of the AMD line-up in having SDMA disabled. That will result in a slightly higher CPU overhead.
SDMA is a faster than regular DMA when it comes to paging and other memory management tasks. It is asynchronous and therefore not cache coherent so it does have some synchronization overhead. It does have other issues as well. Doing SDMA right is, apparently, very hard. AMD disabled SDMA on GFX8 (RX 4xx & RX 5xx) graphics cards seven months ago with the release of Mesa 20. SDMA was disabled on GFX10 series cards (Navi) shortly after those cards were launched. That left GFX9 "Vega" graphics cards as the only modern AMD cards with SDMA enabled on the Mesa RadeonSI Gallium 3D OpenGL driver.
It turns out that SDMA caused some of the same kinds of display corruption problems that prompted AMD developer Marek Olšák to disable it on GFX8 and GFX10 cards is also a problem on AMD APUs with integrated Vega graphics chips. That promoted Marek Olšák to disable SDMA on GFX9 Vega cards with the following patch:
/* SDMA causes corruption on gfx9 APUs: * https://gitlab.freedesktop.org/mesa/mesa/-/issues/2814 * * While we could keep buffer copies and clears enabled, let's disable * everything, because neither gfx8 nor gfx10 enable SDMA, and it's not * easy to test. */ (sctx->chip_class != GFX9 || sscreen->debug_flags & DBG(FORCE_SDMA)) &&
Marek Olšák noted in a comment on the bug report where this patch was proposed, opened 3 months ago, that disabling SDMA will result in higher CPU overhead but the real-world performance impact should be minimal:
"I don't think there is any impact on performance. We use compute for blits now, which should be just as fast as sdma if not faster. There will be decreased cpu overhead without sdma, because the driver won't have to submit two command buffers."
Stability at the price of slightly higher CPU overhead probably worth it.
The rest of the changes in Mesa 20.1.5 are far less interesting. Bas Nieuwenhuizen fixed a uninitialized variable in the AMD RADV Vulkan drivers renderpass, Daniel Schürmann fixed small three issues with the ACO shader compiler, Marcin Ślusarz fixed an out of bounds read on Intel GPUs and Kristian Høgsberg and Lionel Landwerlin submitted some small changes to the Intel ANV Vulkan driver.
The source for Mesa 20.1.5 is available from mesa.freedesktop.org/archive/ and the full release announcement can be read on the Mesa-announce list. Waiting for your favorite distribution to give you the new version through the regular update procedure is likely better than downloading and compiling the source yourself, it is a rather big and difficult compile. Most distributions will have it available within a week or two.