RADV Vulkan Driver Lands Support For External Fences

[phoronix]

Phoronix: RADV Vulkan Driver Lands Support For External Fences

Even with AMD open-sourcing their official Vulkan driver any day now, David Airlie, Bas Nieuwenhuizen, and others independently continue to advance the dissenting RADV Vulkan driver...

http://www.phoronix.com/scan.php?page=news_item&px=RADV-External-Fences

[humbug]

RadV marches on

[Dukenukemx]

Since both drivers work nearly equally in performance, the question is why use AMD's version? Other than it supports more Vulkan features?

[humbug]

Since both drivers work nearly equally in performance, the question is why use AMD's version? Other than it supports more Vulkan features?

Ideally we want not only devs at Red Hat and Valve but also AMD's own devs to be contributing code to the Vulkan driver which people use most frequently. Because when Navi comes out at the end of next year outside devs will not be in a good position to work on support until hardware is released. So we will be playing catch up with RadV again each time there are new architectures or future hardware specific features. At the same time AMD devs will not jump ship to RadV because they have to maintain their cross platform Vulkan driver shared with windows.


There is something AMD can do I guess. Their Windows Vulkan driver is very fast, beats Nvidia. They can work on Linux specific optimization and get their Linux Vulkan driver working at the same Nvidia beating speed. Now that RadV is entrenched they kinda need to achieve that in order to rock the boat and get users and devs to switch. Otherwise RadV is easy for people to stick to and included by default.

[haagch]

Since both drivers work nearly equally in performance

Has anyone tested Doom with Vulkan in wine recently? In the last comparison I've seen from a few months back amdgpu-pro Vulkan was about twice as fast.

In SteamVR Home the performance is sometimes really bad too. E.g. with HTC's driftwood environment the frametimes are completely through the roof on an RX 480. But I'm not sure if it's the source 2 vulkan renderer (Is it using Vulkan on windows?) or radv...

[artivision]

Make RADV a backport project for HD5-6 series GPUs and maybe Fermi, or kill it and contribute your free time to DXVK.

[oooverclocker]

airlied
bridgman

I appreciate the effort Dave put in his RADV driver hugely and I hope that AMD does it even more. Of course this applies to Bas and all other contributors as well.
Following the development of RADV in the last 18 months has been a pleasure, RADV has written an honorable story of success and has achieved a great standing in the open source community.
We should not forget that such stories are only possible with a collaboration of companies with the community. AMD has done exceptionally well to contribute to the Linux environment making nearly completely open drivers possible while we all know how contrarily, how self centered companies can act on the other side.

In my opinion Linux has much to do with love and soul. We should welcome everyone who likes to participate and we should also be empathetic for his concerns to make his commitment rewarding as long as it's not against our persuasion.
AMD would benefit the most from sharing driver code between platforms and so do we. The AMD Vulkan driver is significantly less CPU bound and will be developed by AMD and there is a risk that other RADV contributors like Valve will join. RADV has the advantage that Mad Max works quite well with it while the AMD Vulkan driver seems to have significant issues with this game.
Although RADV's whole development has been very impressive, we have to face that AMD's implementation is performing better in total.

We should also not forget that this is not only a situation that affects the persons I mentioned here. There is also Valve and Feral Interactive, probably Atari, that are affected directly, just to name a few, while others are affected indirectly.
Therefore I have to appeal on Dave and Bas but also on AMD developers, to drink two bottles of mind refreshing beer, imagine the whole open source environment, look at its state and decide whether we can waste these resources to develop two redundand drivers.

Is there no way for a powerful RADV2 to suit all demands, succeeding it's brave predecessor that may give it's life for the sake of a strong, long lasting collaboration? What image does it carry in the perspective of a company who want to port their game to Linux?
No matter how you decide, I am very grateful for every thought you invest in this decision.

[Masush5]

Has anyone tested Doom with Vulkan in wine recently? In the last comparison I've seen from a few months back amdgpu-pro Vulkan was about twice as fast.

That's mostly because radv doesn't support VK_AMD_gcn_shader and Doom ships hand-optimized shaders, right?

[smitty3268]

That's mostly because radv doesn't support VK_AMD_gcn_shader and Doom ships hand-optimized shaders, right?

Yeah, the game doesn't hit the fast path on radv yet.

[roothorick]

Promising. Likely this covers a lot of the internal framework for the more important (at least for VR) VK_KHR_external_semaphore_fd.