Updated August 2020
There are traditionally just two hard problems in computer science — naming things, cache invalidation, and off-by-1 errors — but I’ve long thought that there should be a third: software versioning.
We have a practical problem that will be familiar to anyone in the midst of developing any complex packaged software: we need to ship multiple driver components developed at different cadences and in certain ways, all packaged together and distributed, to be installed as a unit. That disconnect in cadence across the myriad components means aligning the version numbers of each is difficult, and it’s further compounded by the fact we have internal and external versioning schemes for most of those components too.
You can see why there’s a case for adding it to that exalted list of the most difficult problems in our field!
When you download and install the AMD-provided GPU driver you’re getting something with a public name, which today is Radeon Software Adrenalin Edition Graphics Driver 18.8.1, but there’s no solid way for you to map the important bit of the name —
– to what gets placed on disk and loaded by the operating system. And that’s never mind details like whether it’s been WHQL tested or not.
So as a developer writing something using Vulkan, how do you map between the AMD GPU driver that the users of your games have installed, and our versioned Vulkan component in that driver? Until today you ran screaming from the keyboard! We’d like to change that.
What we’ve come up with is a machine-readable mapping that you can integrate into your software, plus this page here with the handy table below that we’ll keep updated whenever a new driver version shows up. The machine-readable mapping is an XML file with a structure that maps from the public driver version number, say 18.8.1, to everything packaged by it, including the Vulkan software component version, something which may or may not change between driver releases. Here’s an example entry for
<driver version="18.6.1" operating-system="Windows"> <whql>Optional</whql> <download-url> https://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Adrenalin-Edition-18.6.1-Release-Notes.aspx </download-url> <internal-version>118.10.21.01</internal-version> <windows-version>24.20.11021.1000</windows-version> <vulkan-version>2.0.33</vulkan-version> </driver>
That gives you what you need to interrogate the internal versioning from the public one for Windows today.
if the driver has been WHQL-qualified or
lets you point users of your software at the right place to get the driver if you need to do that, and AMD GPU Services will let you interrogate the running version number in a robust way by reading
in your game or application.
Update – August 2020
With Radeon™ driver 19.11.1 or newer, you can retrieve the Adrenalin Release version by querying the
struct and accessing the
field. For example, for the driver Radeon™ Software Adrenalin 2020 Edition 20.5.1, it returns
. Be aware though, that the returned type is a string and should not be used for decision making in your application, especially as the user may not be using an Adrenalin driver release in the first place. For instance, OEM and Pro drivers use different versioning schemes and return a string via
. It can be useful to present to users nonetheless.
To access the
struct, use the
extension. It became core with Vulkan®1.2, which is supported in Radeon™ driver 20.1.2 or newer.
If you want to query the Vulkan® driver version, you query for the
. The retrieved value is in a bit field format of 10.22, the first 10 bits for the first component, the second component is always 0, and the latter 22 bits form the last component. It follows the same format as Vulkan®’s
macro, in case you wonder why it’s constructed in this particular way.
For example, the value
map to Vulkan® driver version 2.0.94.
The Vulkan® driver version is used across all the different driver types (e.g. between the Adrenalin driver releases and the Pro drivers).
The AMD GPU Services (AGS) library provides software developers with the ability to query AMD GPU software and hardware state information that is not normally available through standard operating systems or graphics APIs.
Vulkan® gives software developers control over the performance, efficiency, and capabilities of AMD Radeon™ GPUs and multi-core CPUs.