A Closer Look At The AMDVLK vs. RADV vs. AMDGPU-PRO Vulkan Performance

[Michael]

Agreed. Competition is good, but not with drivers. The community should pick one and cannibalize the other and AMD should help along.

When AMD has to continue supporting "AMDVLK" regardless due to the Windows Vulkan support, unfortunately, it's not a trivial route with RADV already working out so well but not easily portable to Windows nor AMD's proprietary shader compiler, etc.

[gnarlin]

RADV at same level or faster good job amd once again

I can't tell if that's sarcasm or not :-/

[Duve]

When AMD has to continue supporting "AMDVLK" regardless due to the Windows Vulkan support, unfortunately, it's not a trivial route with RADV already working out so well but not easily portable to Windows nor AMD's proprietary shader compiler, etc.

Honestly I would think that targeting RADV makes more sense, it's propagates around distributions rather well considering where it is it at in concerns to maturity. If Linux is a target, and you want a wide swath of users, then it hard to argue against it at this point... I would think.

[GruenSein]

Honestly I would think that targeting RADV makes more sense, it's propagates around distributions rather well considering where it is it at in concerns to maturity. If Linux is a target, and you want a wide swath of users, then it hard to argue against it at this point... I would think.

That is a very Linux-centric point of view. Remember: The majority of the GPU-market is on Windows. This means, whatever driver they use there has to be supported. RADV is not an option on windows. Maintaining a second, totally different driver on Linux is a horrible waste of developer resources. Every new GPU would have to be supported on both drivers. Optimizations would have to be done on both drivers. Some might not even translate across platforms.
The Pro-RADV-argument has come up so many times now that I can't help but to think that it is some kind of stubborn clining to the established open source projects like Mesa. Even though AMD has now open sourced their driver after a yearlong effort, people don't seem to find it "open source" or "community driven" enough. Weird.
Finally, chances are that game devs will target AMDVLK since they will have to optimize for Windows anyway.

[airlied]

That is a very Linux-centric point of view. Remember: The majority of the GPU-market is on Windows. This means, whatever driver they use there has to be supported. RADV is not an option on windows. Maintaining a second, totally different driver on Linux is a horrible waste of developer resources. Every new GPU would have to be supported on both drivers. Optimizations would have to be done on both drivers. Some might not even translate across platforms.
The Pro-RADV-argument has come up so many times now that I can't help but to think that it is some kind of stubborn clining to the established open source projects like Mesa. Even though AMD has now open sourced their driver after a yearlong effort, people don't seem to find it "open source" or "community driven" enough. Weird.
Finally, chances are that game devs will target AMDVLK since they will have to optimize for Windows anyway.

It makes a difference if AMD want people to ship their driver. I think most distros dislike shipping thrown over the wall code for many reasons, and until there is a development model for the amdvlk driver, it's hard to want to invest much in it.

Dave.

[nomadewolf]

If AMDVLK is supposed to stay relatively in sync with the windows version, then RADV will probably win the race.

Or it can go the other way around: AMDVLK picks up improvements from RADV and vice-versa, and the Windows version gets synced to benefit from AMDVLK.

[FireBurn]

slacka I don't have any "HD 8000" series hardware but anyhow only have so much time in a day to run tests....

Weren't the 8000 series just rebranded 7000 mobile parts?

[jakubo]

what i would understand from the numbers is that the task has been CPU capped and that latency for radv is lower but may not correspond to more throughput for more demanding tasks when compared to AMDGPU-PRO and AMDVLK

[duby229]

Agreed. Competition is good, but not with drivers. The community should pick one and cannibalize the other and AMD should help along.

I completely agree.

[Kano]

airlied

Basically it should be possible to package AMDVLK relatively easy. It is always good to have got a 2nd choice - the question is just how to select the default Vulkan driver.

Btw. is OpenCL for Polaris 12/Vega already fully open source and packaged for Debian - had problems installing 17.50 with in compute mode with Debian Stretch. With a mesa+llvm backport at least OpenGL+Vulkan works.