The upcoming Mesa driver 23.1 release is sounding like it's going to be pretty great, with the Graphics Pipeline Library ("GPL") being enabled by default, plus we're looking at smaller shader cache sizes too.
We're still around a month away from the release of Mesa 23.1 but that doesn't stop me being excited by it. Going by the current roadmap, the estimated release date is May 3rd. When you will get the update will depend on the usual update times for whatever Linux distribution you're on, and for Steam Deck — likely for the next major upgrade.
Merged into the AMD RADV driver in Mesa a couple of days ago, was a change to enable GPL by default. What this should do, is much improve the stuttery situation that many games on Linux and Steam Deck face when they don't have a shader cache. You can read a whole lot more about how it works in the original announcement post from The Khronos Group who oversee the Vulkan API.
Another recent addition that was merged into Mesa only a day ago, "re-implements the RADV pipeline cache based on the common vk_pipeline_cache", and as a result the developer noted they saw a reduction in the cache file size by "~60%" for single-file disk-cache and "~2%" increase for multi-file disk-cache "due to the overhead from additional small files".
All this and more was summed up in my recent Steam Deck overview news video:
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
19 comments
Merged into the AMD RADV driver in Mesa a couple of days ago, was a change to enable GPL by default.A good day for software licensing!
6 Likes, Who?
Dribbleondo Apr 12, 2023
That video thumbnail reminds me of GMOD lets play videos.
0 Likes
Edit: It seems I have to take back a lot of what I said here. They must have gone on a blitz in the last week or so, as I have found that with tonight's Mesa build, I pretty much have no complaints.
The shader cache is working as expected now.
I don't have to disable gpl for any of the games I've tested (and Rage 2 runs correctly)
Of relevance: It can be disabled if necessary with
---------------------------------------------------
I think that's wrong to enable the graphics pipeline library by default, at least at this time.
It harms Vulkan games (shader cache... see point below)
It harms DirectX 12 (vkd3d-proton), by disabling the on-disk shader caching completely (e.g. no mesa_shader_cache or mesa_shader_cache_sf if gpl). Vkd3d-proton has it's own mechanism, where it caches a primitive and links it in at pipeline time (much like the GPL with DXVK, only it needs to cache more than just its pipeline state)
At this time it's mostly only good for DXVK. (from what I hear, some native Linux Valve titles like DOTA 2, recently ported to Vulkan, also support this but not much else)
Just like mesa_glthread and adaptive sync (also presumptuous defaults). In EVERY case, mesa_glthread is detrimental to me, even in the "poster child" application where it's purported to improve: Bioshock Infinite (native). I patch those defaults in driinfo_radeonsi.h (I change them to false)
I've been using mesa-master (well, "main" now, for the politically correct) for months now so I get the latest commits related to this graphics pipeline library. and I can tell you this gpl is not ready to be enabled by default, or rather, other things won't like it.
As the majority of games I play are DirectX 11 and 9, I have been enabling it by default globally with a variable (RADV_PERFTEST=gpl in /etc/profile.d), and disable it on command line per invocation for games that don't like it. That's fine for me, but could cause problems for those unaware of the problems.
I haven't done a build in some days on gaming system (I don't have this change yet) but now that this is a default, it won't be RADV_PERFTEST="" anymore,
it will be RADV_DEBUG="nogpl" to disable it.
[strike]P.S. I actually have a game that won't launch with gpl, Rage 2. It's a Windows game, but it's Vulkan. It just sits there with the library entry showing "running" until I hit stop. It's waiting for something that isn't coming. That will be a good test tonight, I'll get rid of the variables and try the new mesa build's defaults.
... and Rage 2 launches just fine now (and works normally)
Last edited by Grogan on 13 April 2023 at 12:57 am UTC
The shader cache is working as expected now.
I don't have to disable gpl for any of the games I've tested (and Rage 2 runs correctly)
Of relevance: It can be disabled if necessary with
RADV_DEBUG=nogpl---------------------------------------------------
It harms Vulkan games (shader cache... see point below)
It harms DirectX 12 (vkd3d-proton), by disabling the on-disk shader caching completely (e.g. no mesa_shader_cache or mesa_shader_cache_sf if gpl). Vkd3d-proton has it's own mechanism, where it caches a primitive and links it in at pipeline time (much like the GPL with DXVK, only it needs to cache more than just its pipeline state)
At this time it's mostly only good for DXVK. (from what I hear, some native Linux Valve titles like DOTA 2, recently ported to Vulkan, also support this but not much else)
Just like mesa_glthread and adaptive sync (also presumptuous defaults). In EVERY case, mesa_glthread is detrimental to me, even in the "poster child" application where it's purported to improve: Bioshock Infinite (native). I patch those defaults in driinfo_radeonsi.h (I change them to false)
I've been using mesa-master (well, "main" now, for the politically correct) for months now so I get the latest commits related to this graphics pipeline library. and I can tell you this gpl is not ready to be enabled by default, or rather, other things won't like it.
As the majority of games I play are DirectX 11 and 9, I have been enabling it by default globally with a variable (RADV_PERFTEST=gpl in /etc/profile.d), and disable it on command line per invocation for games that don't like it. That's fine for me, but could cause problems for those unaware of the problems.
I haven't done a build in some days on gaming system (I don't have this change yet) but now that this is a default, it won't be RADV_PERFTEST="" anymore,
it will be RADV_DEBUG="nogpl" to disable it.
[strike]P.S. I actually have a game that won't launch with gpl, Rage 2. It's a Windows game, but it's Vulkan. It just sits there with the library entry showing "running" until I hit stop. It's waiting for something that isn't coming. That will be a good test tonight, I'll get rid of the variables and try the new mesa build's defaults.
... and Rage 2 launches just fine now (and works normally)
Last edited by Grogan on 13 April 2023 at 12:57 am UTC
1 Likes, Who?
Who uses RADV?
Isn't AMDGPU the most prevalent AMD driver on Linux?
I was under impression that RADV is half baked driver implementation from AMD directly?
Did something change in a while or?
Isn't AMDGPU the most prevalent AMD driver on Linux?
I was under impression that RADV is half baked driver implementation from AMD directly?
Did something change in a while or?
0 Likes
Who uses RADV?
Isn't AMDGPU the most prevalent AMD driver on Linux?
I was under impression that RADV is half baked driver implementation from AMD directly?
Did something change in a while or?
Pretty much everyone with a Radeon uses RADV.
AMDGPU is the kernel driver for Radeon cards, RADV is the Vulkan implementation in Mesa for Radeon cards. They are two distinct things.
9 Likes, Who?
fenglengshun Apr 13, 2023
Nice. Though I hear that this doesn't affect DX12 games?
0 Likes
i dont remember when was the last time that nvidia drivers brings performance improvement for linux .
its always fixes or support new linux technology but never performance improvement
its always fixes or support new linux technology but never performance improvement
0 Likes
From whai I've read, the GPL feature needs specific userspace support by the "game".
Is DXVK/VKD3D ready right now?
Is DXVK/VKD3D ready right now?
0 Likes
I was under impression that RADV is half baked driver implementation from AMD directly?You're thinking of AMDVLK, the driver from AMD. It's not widely used but I'm not sure if half-baked is the correct description.
3 Likes, Who?
From whai I've read, the GPL feature needs specific userspace support by the "game".In DXVK from 2.0 I think.
Is DXVK/VKD3D ready right now?
1 Likes, Who?
DamonLinuxPL Apr 13, 2023
Worth to add to use GPL you need good CPU. If someone try it on old or weak CPU then game experience can be worse. The important thing is that you can easily turn it off. Just a reminder, in case anyone else experiences this.
1 Likes, Who?
Worth to add to use GPL you need good CPU. If someone try it on old or weak CPU then game experience can be worse. The important thing is that you can easily turn it off. Just a reminder, in case anyone else experiences this.Too bad, on my system the bottleneck is the cpu already.
Do you have more precise numbers on how much overhead one should expect on cpu side?
0 Likes
You're thinking of AMDVLK, the driver from AMD. It's not widely used but I'm not sure if half-baked is the correct description.You are right thanks for correction.
0 Likes
mr-victory Apr 13, 2023
From whai I've read, the GPL feature needs specific userspace support by the "game".* DXVK 2.0 and above support it, use proton experimental
Is DXVK/VKD3D ready right now?
* afaik gpl is not related with vkd3d so it can't be used with DX12 games
* DX games need to attempt to compile shaders before render time to completely eliminate stutter, otherwise GPL can do only so much.
0 Likes
Worth to add to use GPL you need good CPU. If someone try it on old or weak CPU then game experience can be worse. The important thing is that you can easily turn it off. Just a reminder, in case anyone else experiences this.I don't think this is true.. I've been gaming for a few months now on Mint with gpl enabled manually on 8 years old 4790k (though my gpu is new) and for example on God of War (2018) FPS is very good (though stuttering exists but less so than on Windows 7 + dxvk where gpl does not exist). Another example, Plague Tale Requiem has basically same performance with/without gpl (tho didn't test much without gpl..) on 4790k.. can't say I have seen any performance tanking on my CPU (it runs good btw considering my CPU..)
0 Likes
I don't follow, how do you enable it manually since months?Worth to add to use GPL you need good CPU. If someone try it on old or weak CPU then game experience can be worse. The important thing is that you can easily turn it off. Just a reminder, in case anyone else experiences this.I don't think this is true.. I've been gaming for a few months now on Mint with gpl enabled manually on 8 years old 4790k (though my gpu is new) and for example on God of War (2018) FPS is very good (though stuttering exists but less so than on Windows 7 + dxvk where gpl does not exist). Another example, Plague Tale Requiem has basically same performance with/without gpl (tho didn't test much without gpl..) on 4790k.. can't say I have seen any performance tanking on my CPU (it runs good btw considering my CPU..)
Isn't this a new extension?
Doesn't the GPL need to be explicitely supported by the game engine or dxvk and the likes?
0 Likes
GPL has existed for a while now as development version of RADV mesa driver (but disabled by default since it wasn't fully ready) but anyone who wanted it could pass "RADV_PERFTEST=gpl" as an environment variable to a game (I did this through lutris) and it becomes enabled. It is now becoming enabled by default (after 23.1 driver is released that is) so doing above is no longer needed. It is a driver feature and AFAIK independent of dxvk/proton..I don't follow, how do you enable it manually since months?Worth to add to use GPL you need good CPU. If someone try it on old or weak CPU then game experience can be worse. The important thing is that you can easily turn it off. Just a reminder, in case anyone else experiences this.I don't think this is true.. I've been gaming for a few months now on Mint with gpl enabled manually on 8 years old 4790k (though my gpu is new) and for example on God of War (2018) FPS is very good (though stuttering exists but less so than on Windows 7 + dxvk where gpl does not exist). Another example, Plague Tale Requiem has basically same performance with/without gpl (tho didn't test much without gpl..) on 4790k.. can't say I have seen any performance tanking on my CPU (it runs good btw considering my CPU..)
Isn't this a new extension?
Doesn't the GPL need to be explicitely supported by the game engine or dxvk and the likes?
0 Likes
And today appear this merged in mesa gitlab:
anv: implement VK_EXT_graphics_pipeline_library
https://gitlab.freedesktop.org/mesa/mesa/-/commit/3d49cdb71ee8cb07ca922b9ffa15edd27627959c
also add feature for be possible use in dxvk
anv: introduce a base graphics pipeline object
https://gitlab.freedesktop.org/mesa/mesa/-/commit/b2d3d818d57b9288fcdd98965c81d981540b1aba
anv: Only enable GPL if ANV_GPL=true, or if zink or DXVK are the engine.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/647ca8165407fcdb2695917599a803f8b0c804bb
Last edited by mrdeathjr on 18 April 2023 at 1:43 am UTC
anv: implement VK_EXT_graphics_pipeline_library
https://gitlab.freedesktop.org/mesa/mesa/-/commit/3d49cdb71ee8cb07ca922b9ffa15edd27627959c
also add feature for be possible use in dxvk
props->graphicsPipelineLibraryIndependentInterpolationDecoration = true;
anv: introduce a base graphics pipeline object
https://gitlab.freedesktop.org/mesa/mesa/-/commit/b2d3d818d57b9288fcdd98965c81d981540b1aba
anv: Only enable GPL if ANV_GPL=true, or if zink or DXVK are the engine.
https://gitlab.freedesktop.org/mesa/mesa/-/commit/647ca8165407fcdb2695917599a803f8b0c804bb
Last edited by mrdeathjr on 18 April 2023 at 1:43 am UTC
1 Likes, Who?
Patreon
PayPal
See more from me