AMDVLK vs. RADV vs. AMDGPU-PRO 17.50 Vulkan Performance

[mphuZ]

both

Too many. Only need one.
Let's imagine a situation, when NVIDIA do OpenGL and Vulkan open source driver, similar to AMD will make them cross-platform without putting them in Mesa.

Mesa: Intel OpenGL, Intel Vulkan, AMD OpenGL
Separate: Nvidia OpenGL, Nvidia Vulkan, AMD Vulkan

What do we do? Why would Mesa be needed if the driver developers do not care about her?

[Almindor]

This is typical AMD. It's been like this since they started to "open source" the drivers. There's always the "closed source leftover", the "official oss driver - unfinished" and the "community edition".

Maybe in the next 10 years they can expand to four drivers. Something like "legacy OSS driver" is sure to be required. (with overlap for supported cards of course)

It's good they open-sourced the code of course, but I feel like AMD needs to take control here, shelve the closed source bs already and concentrate on making one driver good.

[bridgman]

This is typical AMD. It's been like this since they started to "open source" the drivers. There's always the "closed source leftover", the "official oss driver - unfinished" and the "community edition".

Actually I don't think it has ever been like that until now, other than the radeonhd/radeon period during 2007/8. Can you cite some examples ?

This is the first time we have felt that the benefits of opening up a closed code base outweighted the benefits of contributing to the community driver, partly because a lot of the hard work was already done before a community driver appeared, and partly because the core code (PAL) is new enough and broadly used enough that ongoing code sharing has a decent chance of being worth the effort.

You could argue that DC was a similar case, but it was actually much easier from an open-sourcing perspective because it didn't have much in the way of functionality that was unused on Linux - just the bits around the edges that interacted with content protection on other OSes - vs the PAL situation where we use the code in other APIs as well as other OSes.

It's good they open-sourced the code of course, but I feel like AMD needs to take control here, shelve the closed source bs already and concentrate on making one driver good.

That has always been our plan, at least for Linux. Nothing has changed since the original AMDGPU presentations in that regard.

[ramrod]

Too many. Only need one.
Let's imagine a situation, when NVIDIA do OpenGL and Vulkan open source driver, similar to AMD will make them cross-platform without putting them in Mesa.

Mesa: Intel OpenGL, Intel Vulkan, AMD OpenGL
Separate: Nvidia OpenGL, Nvidia Vulkan, AMD Vulkan

What do we do? Why would Mesa be needed if the driver developers do not care about her?

You're going to need more than a very unlikely, made up scenario has convince anyone.

[airlied]

There's no reason to stick with just one. They can both be installed at the same time, and it's easy to switch from one to the other per application. Just use which ever one works the best for the specific scenario. There is also the possibility of the AMDVLK picking up improvements from the RADV driver as well, so I would'nt expect the benefits to only go in RADV's direction.

They have had our source code for a lot longer :-)

[airlied]

Yes. Probably, there is regression..

And I would like more tests of "non-Feral" ports, which are developed only for RADV...

The 17.50 binary uses the closed shader compiler, amdvlk uses and llvm fork and radv uses llvm upstream, as AMD improve llvm in their fork and then upstream, radv will gain most of.the same benefits.

Dave.

[andre30correia]

vulkan was created by amd and now they present this crap in their official driver? wtf radv sould continue the amd one is a crap

[bridgman]

So, what we have now is a mess of three different drivers, of which

I think the proper response at this point is "Madame, of what use is a newborn baby ?". Are you saying we should have done all the debugging and performance tuning in secret and only released open source code when all that work was finished ? If so I don't think many people would agree with you.

Now that the hard work of open sourcing the code has been done we can shift more effort onto performance tuning, particularly in the CPU-bound cases.

[mphuZ]

Now that the hard work of open sourcing the code has been done we can shift more effort onto performance tuning, particularly in the CPU-bound cases.

Cool! Finally Vulkan will be useful for the purpose for which it was intended - good performance.

P.S. Should we wait for Radeon Software in 2018?

[bridgman]

P.S. Should we wait for Radeon Software in 2018?

I'm not sure what "Radeon Software" means these days - are you talking about control panels etc.. ?