AMDVLK Radeon Vulkan Driver Updated With A Slew Of Additions

[L_A_G]

...

As I said, it was at best a temporary measure before AMDVLK was open sourced and now that it's been open sourced it's just an unnecessary duplication of effort. RADV could have been a much less ambitious effort and discontinued the day AMDVLK came out and we'd still have DXVK so there's really no need to make clearly false statements like that.

...

I think you're mixing up developer effort to support something with the actual quality of that thing. Application developers were obviously going to focus on RADV before AMDVLK came out and when it's still got more users and what's installed by default on most distros they're obviously going to continue to do so even if all they're doing is perpetuating an unnecessary duplication of effort.

...

The development of a second driver with the same goals is a duplication of effort no matter how you try to look at it. Literally the whole RADV effort is an unnecessary duplication of functionality while game and engine optimizations for it will just a plain waste of effort if sanity prevails and RADV is discontinued.

[torbido]

If AMDVLK doesn't work with Mesa, so what is the point of using it?! There is no driver for my AMD card in their website since 2015!!

[nuetzel]

@Michael:

typo: 'Radeon Vulkan driver driver in place of...'

It was just at the start of October doing my latest AMDVLK vs. Radeon Software vs. RADV Vulkan benchmarks but given this latest heap of new code, it looks like some fresh tests may be on order.

Yes please, radeonsi Mesa git has nice speedup, at least with Polaris due to 'latest' commits by Marek.
Set of patches around

https://cgit.freedesktop.org/mesa/mesa/commit/?id=9b331e462e5021d994859756d46cd2519d9c9c6e

See this, too:

https://lists.freedesktop.org/archives/mesa-dev/2018-October/207232.html

[ms178]

@Michael:

typo: 'Radeon Vulkan driver driver in place of...'



Yes please, radeonsi Mesa git has nice speedup, at least with Polaris due to 'latest' commits by Marek.
Set of patches around

https://cgit.freedesktop.org/mesa/me...6cd2519d9c9c6e

See this, too:
https://lists.freedesktop.org/archiv...er/207232.html

Could you fix these URL's please? I'd like to have a look but they are broken.

[ms178]

Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.

Aye, I agree that this turned out to be rather unfortunate as it took AMD simply way too long to open up AMDVLK to the public. In the meantime RADV earned itself enough mindshare in the community and recieved quite a lot of attention that it is harder now to have one unified AMD Vulkan driver effort. Let's wait and see what a future new graphics architecture might bring to the table where they might need to build a new driver from scratch again.

[Leopard]

As I said, it was at best a temporary measure before AMDVLK was open sourced and now that it's been open sourced it's just an unnecessary duplication of effort. RADV could have been a much less ambitious effort and discontinued the day AMDVLK came out and we'd still have DXVK so there's really no need to make clearly false statements like that.



I think you're mixing up developer effort to support something with the actual quality of that thing. Application developers were obviously going to focus on RADV before AMDVLK came out and when it's still got more users and what's installed by default on most distros they're obviously going to continue to do so even if all they're doing is perpetuating an unnecessary duplication of effort.



The development of a second driver with the same goals is a duplication of effort no matter how you try to look at it. Literally the whole RADV effort is an unnecessary duplication of functionality while game and engine optimizations for it will just a plain waste of effort if sanity prevails and RADV is discontinued.

Sorry but again ; wut?

Do you know the hardware of DXVK dev? Also when he started to invest DXVK?

Let me tell you ; he has RX480 and when he started DXVK ( which is months ago before he showed off Nier ) there was only RADV. He used it , not AMDGPU-PRO which at that time GPU-Pro was struggling to run even native Vulkan titles.

[wsxy162]

there is not that much duplication.
As AMDVLK is essentially their windows driver, it can't be dropped, as you said yourself.
RADV is where currently most game-specific tuning is happening by valve and other developers.
A merge of the AMDVLK-PRO shader compiler would be nice though, as that is superior atm but NOT open source. So AMDVLK is not completely open source yet.
RADV could only be dropped if all game/perf tuning would be transported to AMDVLK and if the shader compiler would go open source and then this thing would need to be accepted by the wider community as supperior.

AMDVLK shares the same code with their Windwos driver, isn't this mean most tunings on Windows also work on AMDVLK.

[L_A_G]

...

The fact that people chose to use RADV, particularly when it was the only alternative for developers who didn't want to work with closed source drivers, doesn't mean that they couldn't have done the same work with with AMDGPU-PRO or that active development of RADV ending immediately as it became unnecessary would have been the end of the world for them. Feedback from this dev you're talking about would probably have been valuable and helped make AMDVLK better.

Seriously thou, nobody actually had to use RADV. Everybody who did, chose to do so.

...

AMD definitely should have gotten AMDVLK open sourced sooner, but I suspect the pretty significant refactoring they had to go trough with for DC/DAL probably threw their original plans out of whack.

As for writing new drivers, doubt they're going to be doing anything even close to as extensive as when they moved to AMDGPU as drivers contain quite a few abstraction layers that aren't hardware dependent. The upshot of this is that more probably than not they're just going to support the new architecture that's supposed to come after Navi under AMDGPU/AMDVLK. After all, limiting AMDGPU to GCN-based hardware and not bothering to add official support for the really early GCN hardware had more to with not wanting to clutter the codebase to a brand new driver with loads of unique branches for legacy hardware.

[gurv]

Personally I've always considered RADV to be a temporary measure at best and an unnecessary duplication of efforts for the most part. We knew that AMDVLK was going to be open sourced and start receiving regular commits since RADV development started, meaning that it's development only made sense for as long as we were still waiting on AMDVLK being made open source. After that happened it's really just been an unnecessary duplication of effort driven by the developers' personal pride and paranoia of companies who haven't been dedicated to open source since the beginning.

Wow, I could not disagree more!
As an AMD customer I hope they ditch AMDVLK in favour of RADV.

AMDVLK has three serious flaws that won't be fixed anytime soon if ever:
- the most serious one: it's not an open community.
AMD controls what gets in based on THEIR very own priority.
The completely open nature of RADV is what enables so many contributions from the likes of Valve and Feral.
- it's shared with Windows.
Meaning features that benefit Windows integration will ALLWAYS have the priority over Linux ones if they conflict.
I'd rather see the sharing be between hardware vendor on Linux than same vendor but cross-os.
- without the PROPRIETARY compiler, it's inferior to RADV.
And if it's proprietary, then why not buy NVidia in the first place.

Personally, I hope Intel comes with some really good discrete GPU in the near future.
That way, I'll always have the option of a fully open-source, fully vendor supported graphics driver.

[airlied]

Being in mesa gives a big advantage to radv, since distros know how to consume llvm and mesa already, the overhead of maintaining radv is negligible if you already ship radeonsi and anv. Packaging amdvlk would cause a lot of pain for most distros, it bundles an llvm fork for example which most distros won't have resources to maintain. I think radv has probably saved its development cost in saved distro nightmares :-)