Join us on our own very special Reddit: /r/Linuxers

The open source Vulkan driver for AMD 'radv' has been merged into Mesa

By - | Views: 14,072
Something I entirely missed when writing about Mesa and OpenGL, is that the open source Vulkan driver "radv" has been merged into Mesa.

See this commit where the magic happened. You can also find Mesa on github.

The radv driver is not yet fully conformant, but fixes have already started rolling in. I imagine getting it fully up to spec won't take long at all.

The next release of Mesa is certainly shaping up to be a rather decent release for open source graphics drivers.

What will be interesting, is seeing what AMD do with their plans to have open source Vulkan support now that radv is part of Mesa directly. Article taken from GamingOnLinux.com.
1 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
22 comments
Page: 1/3»
  Go to:

Shmerl 7 Oct, 2016
Things are really getting good for AMD. I hope by the time Vega 10 cards will come out, amdgpu + Mesa will be in good shape already. Then I'll finally ditch Nvidia for it (and hopefully the added power of Vega will mitigate some performance lacking that still could remain in Mesa).


Last edited by Shmerl on 7 October 2016 at 7:59 pm UTC
DamonLinuxPL 7 Oct, 2016
When AMD release open source Vulkan, I think this RADV should be disabled and stay into mesa code as fallback backend or completly removed.
Shmerl 7 Oct, 2016
By that time, radv can be even better already. AMD developers are also considering stopping their current tedious pre-opensourcing review efforts, and instead complete radv with missing pieces. In the end, as long as result is working well and is open, everyone will be happy.

My only concern now is that radv is using extra step of translating SPIR-V into NIR. That makes compilation of sharders longer, and unless they'll be cached (they aren't yet as far as I know), some parts in games will be slower (any time when new shaders are loaded, like at startup, new levels opening and so on). According to developers, using NIR in the middle actually helps getting better optimized result to feed to the GPU, but as I said, actual compilation with extra step is longer.


Last edited by Shmerl on 7 October 2016 at 7:56 pm UTC
ElectricPrism 7 Oct, 2016
What a glorious day for Canada + Linux, and therefore the rest of the world.


Last edited by ElectricPrism on 7 October 2016 at 7:54 pm UTC
GustyGhost 7 Oct, 2016
Quoting: ShmerlBy that time, radv can be even better already. AMD developers are also considering stopping their current tedious pre-opensourcing review efforts, and instead complete radv with missing pieces. In the end, as long as result is working well and is open, everyone will be happy.

I, too, am considering forgoing AMDGPU and just using Mesa instead since that is the default in so many distributions anyway. Whatever is easier.
mirv 7 Oct, 2016
View PC info
  • Supporter Plus
Quoting: DamonLinuxPLWhen AMD release open source Vulkan, I think this RADV should be disabled and stay into mesa code as fallback backend or completly removed.

It's more likely that AMD will merge with radv in the end, and help it to more fully expose and support some of the underlying hardware. AMD have said before that they expect to kind of meet in the middle with any open source efforts, and radv will help with that.
ElectricPrism 7 Oct, 2016
Quoting: AnxiousInfusion
Quoting: ShmerlBy that time, radv can be even better already. AMD developers are also considering stopping their current tedious pre-opensourcing review efforts, and instead complete radv with missing pieces. In the end, as long as result is working well and is open, everyone will be happy.

I, too, am considering forgoing AMDGPU and just using Mesa instead since that is the default in so many distributions anyway. Whatever is easier.

Depending on your use case AMDGPU can be superior at delivering stability if that's a issue in your current setup.

Nvidia blob has always acted kindof janky and given Linux a "second-world" or "second-class" feel to it, but since I moved to RX 480 support is rock solid.

There are minor setbacks and some games perform worse than others (Ark won't load at all) but I generally do about ~100 FPS @ 1080p, 360 FPS on CS:S and CS:GO, Gary's Mod isn't very optimized and dips but I can't recall dropping below 55-60 FPS on anything.

You do kindof want to be using the latest MESA-git and xf86-video-amdgpu (Post July 2016) equivalent in your distro -- and that's about it.

I got bills to pay before I buy a second RX 480 for my girls rig, her nVidia 970 does what it needs to and has better stability via DVI-D anyways. (The major issue for me was that the NVidia doesn't really play nice with HDMI as the only connection -- you'd think this would be a major oversight as Steam Machines are probbaly 100% HDMI? Weird.)

While the GTX 10XX are outselling the RX 4XX I suspect that on Linux AMD will gain a fair marketshare in the next year so long as people's upgrade cycle coincides (Maybe 30-40% AMD?) A couple years from now I would love to see 70% AMD, or a open source nvidia driver -- thats the only thing that will make me agnostic again to the whole GPU war.
Shmerl 7 Oct, 2016
To clarify for those who aren't familiar with how shaders work. Basically, to make cross platform games (i.e. cross hardware), their graphics commands need to be presented in some generic bytecode fashion. In case of Vulkan it's SPIR-V. Then at runtime, special compilers translate that bytecode into hardware specific instructions (differently on each GPU naturally). Optimization happens on that compilation step, but SPIR-V itself isn't as suitable for optimization as NIR (intermediate format used by the Intel drivers). If I understand correctly, runtime compilation will work like this: SPIR-V → NIR → llvm IR → GPU machine code. That's quite some sequence, but it allows producing better optimized result. Trouble is, since it all happens at runtime, it can cause noticeable delays. Caching of compiled result is a common solution of this issue.


Last edited by Shmerl on 7 October 2016 at 8:25 pm UTC
mirv 7 Oct, 2016
View PC info
  • Supporter Plus
Quoting: ShmerlTo clarify for those who aren't familiar with how shaders work. Basically, to make cross platform games (i.e. cross hardware), their graphics commands need to be presented in some generic bytecode fashion. In case of Vulkan it's SPIR-V. Then at runtime, special compilers translate that bytecode into hardware specific instructions (differently on each GPU naturally). Optimization happens on that compilation step, but SPIR-V itself isn't as suitable for optimization as NIR (intermediate format used by the Intel drivers). If I understand correctly, runtime compilation will work like this: SPIR-V → NIR → llvm IR → GPU machine code. That's quite some sequence, but it allows producing better optimized result. Trouble is that if it all happens at runtime, it can cause noticeable delays. Caching of compiled result is a common solution of this issue.

Because I like technical discussions....I'm fairly certain shader compilation can also be threaded in this case too. Vulkan will allow it, Mesa shouldn't block it. One of the issues with OpenGL was that shader compilation took the source code directly and had to parse that, optimise, etc, all in the context thread. I know drivers might try internally to hide a way a lot of issues with that, but it would still cause a lot of delays. More explicit threaded control, if you know about it far enough ahead of time, can help hide the delays.
So basically, when comparing to OpenGL it won't be so bad, but you still want to cache or build as far in advance as you can.
Shmerl 7 Oct, 2016
Yes, Vulkan should allow better management and offloading of such tasks to multiple threads. That helps, but it will still be up to developers when to load certain shaders. Some tend to do it at startup, which results in massive compilation right away (that's why some games load so slowly first). Some do it gradually, and try to spread the load more evenly. Either way, as you said, caching should better be done as well. I hope radv developers are planning to implement it. Not sure what happens with radeonsi in this regard (with GLSL shaders).
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.
Livestreams & Videos
Community Livestreams
Latest Forum Posts