RADV vs. AMDVLK Vulkan Drivers Continue Stiff Performance Battle

[agd5f]

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.

Well, without copy protection, you can't sell into a lot of markets (e.g., Windows, Chrome, Android) as those are platform requirements. Those are big markets...
Dealing with the copy protection stuff in getting the process in place was a pretty small part. It was just one part of a group of things we couldn't open source. We will would have had to do that work even if we didn't have content protection. I doubt it would have changed the schedule in any major way.

[nanonyme]

Well, without copy protection, you can't sell into a lot of markets (e.g., Windows, Chrome, Android) as those are platform requirements. Those are big markets...
Dealing with the copy protection stuff in getting the process in place was a pretty small part. It was just one part of a group of things we couldn't open source. We will would have had to do that work even if we didn't have content protection. I doubt it would have changed the schedule in any major way.

Also something which has come up before: part of that system is implemented in hardware and leaking too much info risks making entire generations of GPU's unsellable on eg Windows, Chrome and Android

[MagicMyth]

Well, without copy protection, you can't sell into a lot of markets (e.g., Windows, Chrome, Android) as those are platform requirements. Those are big markets...
Dealing with the copy protection stuff in getting the process in place was a pretty small part. It was just one part of a group of things we couldn't open source. We will would have had to do that work even if we didn't have content protection. I doubt it would have changed the schedule in any major way.

I totally get that not doing the "copy-protection" bits would make it impossible to sell in many markets for AMD. I already know why you guys, as well as Google, Microsoft and every other big IT firm put up with it. Basically you have to (or go bust because people can't watch their content). My point was simply how much tax Hollywood and co has pushed onto other industries at no real expense to themselves. Well except when people give up trying to watch some content because it refuses to run on what they currently have. My perfectly good AV system cannot play UHD Blue-Ray movies because it it is HDCP 1.4. It can play TrueHD and DTS-HD brilliantly but not if its a new movie. Thus I would have to fork out £300+ just to be able to do what I fundamentally already can do. That's money copy-protection is costing me!

/END-RANT

PS Glad to hear in this case the copy-protection bits didn't have much of an impact.

[swizzler]

I'm going to reiterate what I said before. I do not like having 2 drivers for the same thing. Yes they are OSS both, yes they can be "swapped at runtime" even. Yes they create competition.

Don't think for a second that the AMDVLK driver is open in the community sense. It is a dump of the ported windows driver from perforce. No end user or distro will ever get a bugfix merged back into this thing. If you are happy with catalyst, then you can be happy with amdvlk.

My guess is that AMDVLK exists because AMD mesa drivers did not have the bandwidth to implement vulkan, and AMD was humiliated by the fact that volunteers implemented a better driver *sooner* on top of mesa. This effort undermines the community developed vk driver and mesa in general, but I doubt google, redhat, or valve are fooled for a second.

[agd5f]

Don't think for a second that the AMDVLK driver is open in the community sense. It is a dump of the ported windows driver from perforce. No end user or distro will ever get a bugfix merged back into this thing. If you are happy with catalyst, then you can be happy with amdvlk.

We are happy to accept patches. We have gotten and integrated a few fixes already.

My guess is that AMDVLK exists because AMD mesa drivers did not have the bandwidth to implement vulkan, and AMD was humiliated by the fact that volunteers implemented a better driver *sooner* on top of mesa. This effort undermines the community developed vk driver and mesa in general, but I doubt google, redhat, or valve are fooled for a second.

The plan was always to open source our vulkan driver. We announced it would be open source at about the same time it was announced in general. It took a while to open source for the reasons I mentioned above

It's open source. Developers can do what they want with their free time.

[Almindor]

Maybe if they follow the vulkan spec properly instead of doing driver-specific hacks, that AAA game will work fine on pretty much any driver?

That's never the case because the drivers have bugs that only show up in said AAA titles (e.g. when put to proper test)

[Almindor]

Valve seems to lead RADV development and Feral also contributes to it. That might indicate what game developers care about.

I agree. I think it'd be best if RADV ends up being the standard linux driver with AMDVLK just a "official features dump" from AMD that can be used by the community as a source of inspiration so to speak. It's really sad AMD didn't open source AMDVLK from day 1. Would've saved a lot of trouble and effort.