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

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

When AMD release open source Vulkan, I think this RADV should be disabled and stay into mesa code as fallback backend or completly removed.

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

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

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.

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

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.

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.

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

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).

Caching 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

You 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:

It'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).

Good, but where are all upcoming games that will support Vulkan now? The list still looks quite static on wikipedia, except some Android games.

Good, but where are all upcoming games that will support Vulkan now? The list still looks quite static on wikipedia, except some Android games.

No, I think the order goes the other way. First, the spec becomes available and whatnot. Then, you get tools for using it and the graphics card drivers make it even work on people's computers. Sub-step: The drivers and tools reach the point where it runs well and fast.
After that, people writing games will start to think it could be worth using it in their game. There's no point using Vulkan in your game if that means buyers won't be able to run it. So, news like this represents important steps. Only after a few more steps of this sort will it be worth asking where the games are, because right now doing a game using Vulkan is an experiment, not a commercial decision.

It's only getting better on the oss front! http://www.phoronix.com/scan.php?page=news_item&px=13-Patches-Finish-ST-Mesa-45

Just waiting for AMD to release it's next series, The quicker I can jump back to AMD from this 1080 the better!

Just recompiled Mesa from git and pulled in the Vulkan updates and got that working on my machine. Definitely not ready for prime time, although great to see such progress.

Dota 2 caused a kernel hang after less than a minute the first time I tried it - although that's probably more of an amdgpu kernel module bug. I wouldn't want to trust it for an hour long online game.

The Steam overlay is completely garbled when running the Talos Principle - however I notice this happens on AMDGPU-Pro's proprietary Vulkan drivers too. At one point I also had the background graphic in the menu appear corrupted, although the menu text and in-game graphics seemed okay. I also noticed that I could not select Ultra for all graphical settings if Vulkan was enabled. However the maximum allowed settings did show an improvement of over 10 FPS when compared to Mesa also at those slightly reduced settings (at 2560x1440). Unfortunately the game would also usually crash when switching from Vulkan back to Mesa, as well as freeze up when I tried to exit the game (forcing me to kill the process manually).

The Kronos cube demo shows some flickering, as does the tri demo. Not sure if that's normal, but the other demos don't seem to do that.

vkQuake ran great. Better than Vulkan on AMDGPU-Pro actually, since the proprietary driver would intermittently fail to launch the game (a bug which has been reported).

In short, Mesa's Vulkan support does work and already shows a significant performance improvement over Mesa's OpenGL implementation, but it's probably not stable enough that you'll actually want to use it just yet. Since it was literally just merged yesterday, this shouldn't come as a surprise.


Last edited by boltronics on 8 October 2016 at 4:06 pm UTC

Yep. This is great news. Also, I don't expect AMD to release a competing open source driver. The radv will be the priority and hopefully AMD will contribute to improve it down the line.

Also now we are at OGL 4.5. I hope they can focus more on bug fixes and things like the shader cache, which has been planned but took at back seat.

Graphics driver's have always been a bit of magic to me. I have a low end AMD card:
Advanced Micro Devices, Inc. [AMD/ATI] Mullins [Radeon R4/R5 Graphics] [1002:9851] (rev 05) (prog-if 00 [VGA controller])
And I've always had trouble figuring out how to optimize my usage of it, when/if I can use AMDGPU (and/or -PRO?). Even when asking (ubuntuforums) I find it difficult to follow - I wonder if I should get some custom kernel or so? When?

I recently switched from ubuntu's repo-radeon FOSS driver to padokas to try them out and see if there was a difference, and I can't say I've noticed that much. Are these new features mainly for high end or newer graphic cards?

About shaders, what are they? I played FS2Open (Freespace2) and for a long time it ran horribly even on rock bottom settings, then someone suggested disabling GSLS-shaders and BOOM, all other settings at max and it looks stunning. Why is that?

And I've always had trouble figuring out how to optimize my usage of it, when/if I can use AMDGPU (and/or -PRO?).

As an Nvidia user, I have the same problem. Too many names to keep track of. If I switch to AMD, I'll have some studying to do.

About shaders, what are they?

Shaders are little programs than run on your GPU. They replaced the fixed logic that present in the rendering pipeline of the older graphics cards (then 3D accelerators). What's a rendering pipeline? Uhm, if you really want to know more about the subject, have a study session on the internet. It's a fascinating subject, but it can be quite hard when you first start out.

And I've always had trouble figuring out how to optimize my usage of it, when/if I can use AMDGPU (and/or -PRO?).

As an Nvidia user, I have the same problem. Too many names to keep track of. If I switch to AMD, I'll have some studying to do.

About shaders, what are they?

Shaders are little programs than run on your GPU. They replaced the fixed logic that present in the rendering pipeline of the older graphics cards (then 3D accelerators). What's a rendering pipeline? Uhm, if you really want to know more about the subject, have a study session on the internet. It's a fascinating subject, but it can be quite hard when you first start out.

Hum, well, I guess I'll leave it at that :P It was funny how just disabling GSLS instantly made my FS2 game run super nice on mega settings, but perhaps that was just some bug in that game and not anything to do with shaders in general.

If I could wish for an article, it would be a "what foss driver to use for your graphics card, and HOW!" or some such, with like nice tables describing each case, updated regularly with news etc. And also, in depth how-tos on how to enable stuff in kernels and such. I am quite skilled at other terminal-operations and linux-know-how, but this stuff has always confused me - there seem to be no simple answers/wikis.

edit: wtf quote tags


Last edited by buenaventura on 10 October 2016 at 11:04 am UTC