RADV Radeon Vulkan Driver Is Still A Better Bet Than AMDVLK In February 2018

[phoronix]

Phoronix: RADV Radeon Vulkan Driver Is Still A Better Bet Than AMDVLK In February 2018

With the AMDVLK Radeon Vulkan driver that AMD open-sourced in December continuing to be updated in weekly batches with new Vulkan extensions / features / performance optimizations and the RADV Mesa-based Radeon Vulkan driver continuing to march to its own beat, I have spent the past few days conducting some fresh benchmarks between the AMDVLK and RADV Vulkan drivers with RX 560, RX 580, and RX Vega 64 graphics cards.

http://www.phoronix.com/vr.php?view=26010

[gurv]

I think AMD should stop developing AMDVLK (on Linux that is) and instead contribute to RADV.
I mean they already had the resources to develop a Linux specific OpenGL driver.
Developing a Vulkan driver can't be more costly, right?

In my opinion, there are better synergies between vendors on Linux then between OSes for a single vendor and it will result in a driver better suited to Linux in the long term.
RADV also has the benefit of a more open development.
(On that topic, I've not seen any sign of outside contributions to AMDVLK to date. Valve doesn't seem to want to invest in it as far as I can tell).

I'd rather AMD invest resources on getting Freesync to work than with a separate Vulkan driver.
I'm still waiting to finally take advantage of my Freesync monitor

[eydee]

Use both drivers at the same time for double performance!

[R41N3R]

Impressive results for RADV and I think in this case competition is good :-)

[gnarlin]

AMD have specifically stated (at FOSDEM 2018) that they don't intend to have AMDVLK live inside of mesa. I think that is a huge mistake if they intend the community to have any interest in participating in it's development. AMD were simply way too slow off the mark before some capable members of the community (you know who they are) got fed up and started saying: "how hard could it be?"

[Marc Driftmeyer]

Very soon AMDVLK will leap frog RADV. The maturing stack of libdrm and all that is coming in with SPIR-V, etc., will show up.

[cb88]

Very soon AMDVLK will leap frog RADV. The maturing stack of libdrm and all that is coming in with SPIR-V, etc., will show up.

Unlikely, RADV can just do the same... it would probably be better if they cleaned up the windows support for Mesa3d and used it on Windows.

[mphuZ]

..they don't intend to have AMDVLK live inside of mesa. I think that is a huge mistake...

They don't owe you anything.
On the contrary, it's amazing that they have such a large open and cross-platform code!

You should respect the choice of the developer, if it is so convenient (AMDVLK) for them.

[Michael]

AMD have specifically stated (at FOSDEM 2018) that they don't intend to have AMDVLK live inside of mesa. I think that is a huge mistake if they intend the community to have any interest in participating in it's development. AMD were simply way too slow off the mark before some capable members of the community (you know who they are) got fed up and started saying: "how hard could it be?"

They don't need it to live in Mesa since it doesn't tie into any of the Mesa/Gallium interfaces.... Rather it uses the open-source XGL/PAL component. If it lived within Mesa it would only complicate their support on Windows.

[tildearrow]

Typo:

When running with high image qualty settings,