With recent commits that fix bugs and allow newer Vega cards to pass tests for official conformance, development for radv continues apace. It’s a good time to look back and talk about just how far the driver has come in such a short time.
AMD’s recent open-sourcing of their Vulkan drivers is a great thing and it’s something well worth mentioning and celebrating. That said, those of us running Mesa on AMD cards have had a working alternative for a long time. radv is the brainchild of David Airlie and Bas Nieuwenhuizen and it’s been under active development for under a year and a half. In that short span of time, it’s made great leaps and vast strides in providing a well-performing and functional Vulkan driver for AMD users.
Taking a step back, Vulkan is a low-level API that was created by the Khronos Group as a truly cross-platform project. I won’t really delve into the technical aspects but, in partial and broad strokes, one of the main abilities of Vulkan is to lower CPU usage and make use of multiple cores more efficiently. It’s already being widely adopted in mobile devices and we’ve begun to see adoption in various toolkits and engines that run on Linux as well. It’s unlikely to surpass OpenGL in usage anytime soon (nor does it necessarily aim to) but I think it’s fair to say that we’ll be seeing more and more Vulkan-capable programs as time goes by.
I’ve been keeping tabs on radv’s development from the very beginning. As someone running an old AMD FX-8350 CPU on his desktop, an API that could minimize the relatively poor single-threaded performance bottleneck common in many games was naturally appealing. David and Bas originally started work on the project when they realized they might as well write a driver themselves instead of waiting for an open source Vulkan driver. The initial public release was in July of 2016 and it only rendered a few simple demos. By August of that same year, it could (mostly) run DOTA 2. A month after that, The Talos Principle worked. Less than a year from that first version that could only run demos, it passed most of the conformance tests in the official Vulkan test suite.
In short, radv’s development has been nothing but meteoric. Along the way it’s become an official part of the Mesa project and we’ve been able to enjoy a mostly hassle-free Vulkan experience on AMD cards for a some time now. The aforementioned pass for Vega cards follows official certification in October of earlier card architectures. It’ll still be a while before newer cards are officially certified on radv, however, as it depends on paperwork being submitted to Khronos first.
So, you might be wondering, what’s the day-to-day experience of running radv like? Late last year, I upgraded to an RX 480 GPU in part to muck about with Vulkan. Early days, there were some stability issues which caused crashes or even system hangs. Those problems have all been resolved, so far as I can tell, in both the stable Mesa versions as well as the latest git versions. There are occasional regressions in the git commits but they're few and far in between. It's generally been a very stable in my experience.
My interactions with Vulkan mainly come from running emulators these days. I’ve got quite a large collection of games I’ve ripped from discs over the years and, from time to time, I get the urge to revisit my collection without bothering to dig up my old consoles. With things like adapters for Gamecube controllers for the PC, games like Super Smash Bros. Melee running on the Dolphin emulator remain a popular pick whenever I’ve got friends over. Aside from Dolphin, many emulators such as RPCS3, libretero and some of its cores, as well as (recently on Linux) PPSSPP all support the Vulkan API. With some exceptions here and there, due to the capricious nature of some games and emulators, performance is nearly always superior on the Vulkan renderer on my machine.
Aside from that, there are a few ports and titles on Linux that take advantage of Vulkan. Of these titles, the ones I’ve played the most are The Talos Principle and Mad Max. In both games, my performance was pretty CPU-bound and poor in the OpenGL renderer. Vulkan changed all that, with Talos easily reaching 100+ FPS and Mad Max becoming smoother and my minimal FPS increasing. I was able to crank up the graphical settings on both without sacrificing much of my newfound performance and take full advantage of my RX 480 as a result. I know that most gamers will have had more powerful CPUs and seen much less of a difference but, for me, these two titles provided a stark vision of what could be accomplished on this new API. And that was without years of engine optimizations and maturing drivers!
This isn’t to say that it’s all roses. After Dawn of War III launched, and there was a free weekend, I found that OpenGL performance was superior to Vulkan in that title. I’m sure many more bug fixes and improvements have been made to radv and DoW III since but it goes to show that things aren’t quite so straightforward. Likewise, with DOTA 2, running it with Vulkan doesn’t seem to make that much of a difference. I can’t say I’ve played much but my own quick (and very limited I should emphasize) benchmarks show that the game performance is roughly comparable with both APIs. I’m not sure if that’s down to the engine or the drivers but, either way, I’m confident both will get better over time.
It should also be mentioned that I gave the newest Doom title a go through Wine when it had a free weekend some time ago. id Software continue to write their engines around OpenGL and their latest version also supports Vulkan. It’s almost tragic how well the game ran for that hour or two I played; it looked absolutely beautiful and performance was buttery smooth. I can’t say that I use Wine much nor would I recommend buying non-native games. That said, if you already own the game: it works great and more’s the pity that Bethesda is unlikely to bring it to Linux.
There you have it—radv has had an amazing first year and a half and things are only poised to get better. With more people than ever contributing Mesa and radv, including Valve and Feral Interactive, I have no doubt that future Vulkan titles will run very well on open drivers. It’ll be interesting to see how much of AMD’s own driver gets worked into radv, too. There’s no doubt in my mind that 2018 will be a very interesting year for AMD graphics card owners on Linux.
Quoting: Luke_NukemIf I had one wish in life, it would be to flog all the head honchos of Zenimax and Bethesda with a flexible cane until they admitted that supporting Linux is a worthwhile endeavour.
One wish in this life? As a Linux advocate, i sure appreciate this noble wish.. ...yet if i was to have this kinda power, i'd STILL end all wars first, dammit
Quoting: GustyGhostHopefully, by the time this arrives downstream, AMD's DC code will be properly reworked for merge into mainline kernel.
AMD display code (DC) is already merged in Linux 4.15.
Last edited by Shmerl on 31 December 2017 at 3:51 am UTC
Quoting: GustyGhostOh wow I just realized my source on AMD DC is over a year old. Looks like you're right. Now I await downstream.
I already tried it out in Debian testing (using 4.15rc5 from exprimental).
Quoting: Perkeleen_VittupääQuoting: Luke_NukemIf I had one wish in life, it would be to flog all the head honchos of Zenimax and Bethesda with a flexible cane until they admitted that supporting Linux is a worthwhile endeavour.
One wish in this life? As a Linux advocate, i sure appreciate this noble wish.. ...yet if i was to have this kinda power, i'd STILL end all wars first, dammit
Quoting: KohriasI actually run a very similar hardware setup, BTRE ;) And as you I had a nice performance boost in MadMax. I havent done much with emulators yet. Could you share some tips on how to setup a good emulator environment? To me it seems like there are a lot of programs you have to use together.If you're looking for an all-in-one sort of solution, try retroarch. It's a frontend for libretro. You need to configure some paths for where it puts its files but other than that, you can keep it updated from the program itself and you can download the various emulator 'cores' (ported external emulators) and have a unified interface for them. You don't have to worry about configuring input devices or graphical backends for most things after that. Switching between, say, playstation and PC-98 games seamlessly is pretty cool.
I still use dolphin-git and ppsspp-git outside of retroarch, though, but that's mostly because I like to test the latest changes (like some of the vulkan improvements) and retroarch can be a little behind upstream. Maybe I'll write up a guide one day on GOL, but it's not too hard to figure out tbh. There's wikis and guides elsewhere that should help you.
Quoting: BTREI still use dolphin-git and ppsspp-git outside of retroarch, though, but that's mostly because I like to test the latest changes (like some of the vulkan improvements) and retroarch can be a little behind upstream. Maybe I'll write up a guide one day on GOL, but it's not too hard to figure out tbh. There's wikis and guides elsewhere that should help you.For people on Ubuntu (or derivatives) both dolphin and ppsspp have seemingly official PPAs with git builds.
Oh and the name doesn't mean anything but coincidentally could be pronounced as "Buttery" which suits me just fine.
See more from me