Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

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

By - | Views: 19,215
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
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. Find me on Mastodon.
See more from me
The comments on this article are closed.
18 comments
Page: 1/2»
  Go to:

Shmerl Oct 7, 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 Oct 7, 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 Oct 7, 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 Oct 7, 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 Oct 7, 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.
ElectricPrism Oct 7, 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 Oct 7, 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
Shmerl Oct 7, 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).
Shmerl Oct 7, 2016
Quoting: swickCaching shaders (or rather pipelines, because shaders can compile to different variants with different pipelines) is the responsibility of the application. https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html#pipelines-cache

It's good if developers know that and implement such caching. Do actual current Vulkan games implement it?


Last edited by Shmerl on 7 October 2016 at 8:44 pm UTC
Furious Oct 7, 2016
Quoting: swickYou guys seem to believe that long compilation is responsible for stutter. This is true for OpenGL because the pipeline in OpenGL is only known when a draw command is issued. Compiling the shaders in gallium3d is then done in worker threads, so you already have threading but it doesn't help that much because the driver needs the compiled shader *now*.

In Vulkan you can construct a pipeline without context (so you can construct it on arbitrary threads) and then compile the shader (again, threading if you want) without there ever being a draw command that uses the compiled shader. This means that you can create the pipeline and compile the shader before you actually need it.

edit:

QuoteIt's good if developers know that and implement such caching. Do actual current Vulkan games implement it?

Pretty sure they do but I haven't looked into it - mostly because I don't have any Vulkan games installed

Watch the "best practises for vulkan" from khronos youtube chanel. Epic and Doom devs are talking exactly about your concenrs (Im pretty sure).
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring 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.