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

[Jumbotron]

I'm sorry. But RADV wins most of the tests and when it does not it loses by a handful of frames which is still lower than the 15% threshold that most visual experts say you have to have to be able to perceive a difference in the real world. Either RADV will continue to improve faster than AMDVLK and even crib some of their code or AMDVLK will. Either way iron sharpens iron and we will get the Vulkan driver Linux needs. Vulkan is still beta and not production ready like OpenGL. It will get there. So stop bitching everybody and start coding or at least submit detailed bug reports.

[Almindor]

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.



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

Let me first say that I really appreciate ALL your effort on the OSS side and your time here responding to our rants too. I also realize that a lot of the split atm. is due to llvm/upstream issues and the fact that lots has changed lately in the driver architecture. But I think it's worth noting that AMD has been on the OSS path for quite a long time now and I can't help but feel the effort is somewhat half-assed. I don't think it's the team's fault, if anything it stinks of typical corporate priority problems.

It does seem like the light at the end of the tunnel in 2018. At least for usability if not performance.

[mphuZ]

are you talking about control panels etc.. ?

Of course

[pkunk]

What I would like to see, and I'm not sure if it can be done already is a method to set one as the default. Does anyone know of a way to do that?

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

[Shnatsel]

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.

Oh, so at least the shader compiler is shared with radeonsi/radv? That's a relief.

AFAIK radv uses a SPIR-V to NIR pass, then runs optimizations on NIR, translates NIR to LLVM bytecode (?) and then compiles it for the hardware. So at least the LLVM backend should be shared.

Could you clarify how exactly that works?

[ramrod]

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json

Wouldn't that only apply to that specific shell?

[bridgman]

But I think it's worth noting that AMD has been on the OSS path for quite a long time now and I can't help but feel the effort is somewhat half-assed. I don't think it's the team's fault, if anything it stinks of typical corporate priority problems.

Are you talking about a vague sense of dissatisfaction (like wishing we had Intel's R&D budget), or are there specific things you think we should have done differently ?

https://www.reddit.com/r/Amd/comment...ia_rd_budgets/

[Luke_Wolf]

bridgman
So the difference between AMDVLK and -PRO is that AMDVLK is using LLVM and -PRO is using some internal AMD proprietary compiler? Is the long term goal for AMD to bring -PRO/Catalyst onto LLVM or is this split in software going to continue for the foreseeable future?

[Leopard]

So it looks like AMD open sourced a very old Vulkan driver which is not optimized or they kept the secret formula on closed source driver and released a stripped version of Vulkan driver.

AMD side looks like a real mess but standart user which does not want to hop between drivers should stick with Mesa.

I hope AMD devs ( Marek mostly ) can implement OpenGL compat profiles in Mesa while Dave Airlie and others complete missing bits of RADV with help this AMDVLK driver.

[oooverclocker]

Some things are quite suboptimal. From the perspective of the whole thing(Linux) it doesn't look so rational to do things the way several parties do. Although they are kind of in the same boat.
That counts for those who started to adopt party for one driver as well as companies and developers who are doing their own thing. I would be very happy when we could decide constructively how to act in concert. Please remember that these drivers are mainly used in desktop systems. You know where we are and how ambitious our goals are.
Again, the last years have given wonderful results - try your best to keep this spirit in development alive. When the year of the Linux desktop shall happen eventually, we can not venture any weakness!
When specific OSes that one can have a big problem with will manage critical devices in the future, hell, I do not want to be responsible for not preventing this to happen just because of vanity...