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

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.

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.

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

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

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