RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle

[agd5f]

It doesn't with the llvm compiler backend, so parts of the AMDVLK code has, but major parts don't.

AFAIK, the vulkan team plans to move to LLVM for all supported OSes once it's on par with our current internal compiler on those OSes. Linux just picked it up first because we couldn't open source our old internal compiler. LLVM provides a lot of flexibility that our internal compiler did not. I think it will be a net win for everyone in the long term.

[agd5f]

I understand that the original hold up was largely due to legal reasons but that does not change the case of which takes less effort? And it certainly takes more than very limited manpower to do their code drop. Don't underestimate the effort involved in the platform specific bits even if it makes up only 10% of the codebase. The in-kernel driver and parts of the compiler backend are quite drastically different on Linux compared to Windows and require very platform specific optimisations to get the very best performance on-top of the extra testing required.

I'm curious if the legal reviews still and will persist for AMDVLK? bridgman do you guys still have to go through those reviews before your code drops or is it non-existant now?

It was never really legal reviews. The three main reasons it took a while to open source were:
1. Resources. We were busy getting vulkan out the door and adding new asic support and getting regular driver releases out the door.
2. Compiler. We couldn't open source our internal compiler so we had switch to LLVM. The vulkan team was planning to do that anyway because LLVM provides a lot of flexibility that our old compiler didn't provide. That said, supporting multiple compiler backends on your driver is a pretty major undertaking.
3. Coming up with a plan and process to expose the parts of the driver we can while protecting the parts we can't (e.g., content protections stuff, support for other OSes, etc.) and provide regular updates without needing lots of review for each release and to integrate community contributions in a reasonable way. It's still not perfect, but we had to balance getting the perfect process and actually getting the code out.

We have process in place so as you can see from our regular updates, we don't have to do any formal "reviews" before we push updates.

[tarceri]

Once the CPU bound issues are resolved eventually, AMDVLK and RADV will merge with AMDVLK effectively absorbing the bits that make sense. Or people can keep them separate with AMDVLK absorbing the bits and expanding its overall lead as the code base matures and the cross-platform strategy steadily matures with shared optimizations.

This makes no sense, the drivers will never merge they have been designed very differently. In future however radeonsi and RADV will share even more code paths. RADV dev's already actively take performance hints from AMDVLK so I'm not sure why you think AMDVLK is the only driver that can expand its lead. We likely need to improve shader generation but we have known about that for a while, it's really just a matter of pinpointing where we need to make improvements which can be time consuming. The good thing is that because RADV (and radeonsi in future) use NIR Intel and others are also continuously working on better shader optimisations that can be shared, while AMD (AMDVLK devs) should also be landing opts in LLVM mainline that RADV/radeonsi can make use of also.

[dungeon]

RADV dev's already actively take performance hints from AMDVLK

That for sure, in decades i only see actively taking something in various ways And really not developing nothing new much.

...so I'm not sure why you think AMDVLK is the only driver that can expand its lead.

I am sure that i know why That is because hardware makers should make drivers, that is also because software lovers have desire to made their own hardware. While on linux probably just to please minorities the opposite is half-true.

I even think that this AMD case, from a user perspective exactly that makes bad light about linux in general If whatever company wants to do opensource driver we should please that, they should do it for their own hardware, otherwise we will approaching apocalipse - that is to every game dev ship their own driver with the game.

Who knows, maybe that is the best solution "once device - one game" sounds fine even for bussiness

[dungeon]

So long for so called "opensource"

[shmerl]

Read the github. AMDVLK is not currently supported because of poor support for what Mr Rebhole is doing.

That doesn't answer my question, whether it's a problem with amdvlk, or with dxvk itself.

[dungeon]

That doesn't answer my question, whether it's a problem with amdvlk, or with dxvk itself.

Judge for yourself:

AMD amdvlk

• Not supported, and any issues with this driver will be ignored. Use RADV on AMD cards instead.

https://github.com/doitsujin/dxvk/wiki/Driver-support

That sounds to me to be more political than anything else, isn't it?

[arunbupathy]

I'm a little worried that people say "merge AMDVLK and RADV," if they're doing so without thinking about what they really mean. While it is true that having the development efforts distributed over two projects (which are essentially trying to achieve the same goal) makes it less efficient, it's not like the AMD devs are doing extra work. They'd still have to write the OS agnostic Vulkan bits anyway.
The way I see it, there is more advantage to having both projects out in the "open". More often than not there are multiple approaches to solving the same problem. Meaning, that by independently developing AMDVLK and RADV in parallel, there is scope for coming up with better solutions. It's not to say that either of the devs are not trying to figure out the best way to code their drivers, but that being independent of each other implies that they can take different paths. In fact, each driver's basic architecture might not allow for certain algorithmic ideas to be implemented. So having both can lead to better driver architecture, which, in my eyes, is a far far greater gain.

[Snaipersky]

That doesn't answer my question, whether it's a problem with amdvlk, or with dxvk itself.

Its an issue with how the driver operates as far as I can gather. Not inherently a problem with it, but done in a way that the author does not wish to invest the resources to cope with. Mesa is more common, so he is supporting that.

[MagicMyth]

AFAIK, the vulkan team plans to move to LLVM for all supported OSes once it's on par with our current internal compiler[...]

It was never really legal reviews. The three main reasons it took a while to open source were:
1. Resources. We were busy getting vulkan out the door and adding new asic support and getting regular driver releases out the door.
2. Compiler. We couldn't open source our internal compiler so we had switch to LLVM. The vulkan team was planning to do that anyway because LLVM provides a lot of flexibility that our old compiler didn't provide. That said, supporting multiple compiler backends on your driver is a pretty major undertaking.
3. Coming up with a plan and process to expose the parts of the driver we can while protecting the parts we can't (e.g., content protections stuff, support for other OSes, etc.) and provide regular updates without needing lots of review for each release and to integrate community contributions in a reasonable way. It's still not perfect, but we had to balance getting the perfect process and actually getting the code out.

We have process in place so as you can see from our regular updates, we don't have to do any formal "reviews" before we push updates.

Thanks for that detailed behind the scenes information. Will be interesting to see how the LLVM backend will affect Windows. Should make for a more direct comparison for Michael to do some more tests between Linux and Windows.

The hard work of both driver teams is much appreciated.

On a side note of what you mentioned on "Coming up with a plan and process to expose the parts of the driver we can while protecting the parts we can't (e.g., content protections stuff[...]". The argument for copy protection is basically an economical one. The proponents of it say they must do it because all those pirates (me hearties) will keep them from making enough money. But what is the economical hit on the ecosystems that must support said demands? How much simpler would the AMDVLK release have been without having to deal with such restrictions? Thats just one example. And thats not counting the practical impact the delay has had on the Linux scene. Yes I am no fan of all this copy-protection hassle but I understand AMD's pragmatism.