Radeon Vulkan Driver Benchmarks: AMDVLK 2018.4.2 vs. AMDGPU-PRO 18.40 vs. Mesa 18.2/19.0

[BNieuwenhuizen]

4. IIRC, RADV copied a lot of code from amdvlk. Clearly, amdvlk has a good implementation.

We copy some ideas but almost 0 code. There is one shared libary mostly about texture layout rules.

Michael We were kind of puzzled that the numbers here were pretty bad for RADV compared to AMDVLK on Vega since we were seeing them being on par the last few months. After some investigation I think this is due to some change (still being bisected) that is hitting 4.20 . It might be interesting to take 4.20-rc3 and compare e.g. Talos. Numbers here suggest they should be pretty much on par (with 4k resolution, ultra graphics + 8.4 mpix internal target + 8x MSAA, but I guess whatever pts sets is close enough).

[Marc Driftmeyer]

Gee, I recall saying AMDVLK would surpass RADV and got crapped on for it. Proof is in the pudding.

[airlied]

Gee, I recall saying AMDVLK would surpass RADV and got crapped on for it. Proof is in the pudding.

Don't worry you'll be wrong again, this looks like a kernel regression or change that affected radv worse than amdvlk.

Dave.

[marek]

Ugh, all these AMD Vulkan driver implementations seem like a waste of developer resources. Why not consolidate development effort around one and make it the best?

The initial intentions were good and there was void at the beginning that needed to be filled. Now it's just about egos and tribalism.

[Maslou]

Mikl.
When will you test the proton? Now it is very important to choose a video card / driver. Native Linux games are more predictable in performance. In any case, thanks for the work!

[chimpy]

The initial intentions were good and there was void at the beginning that needed to be filled. Now it's just about egos and tribalism.

I'm guessing that's a reference to Bas and Dave, but have Valve or Feral reached out to contribute to AMDVLK? Is it even possible for anyone outside AMD to contribute to AMDVLK at the moment?

[GruenSein]

I'm guessing you're talking about Bas and Dave, but have Valve or Feral reached out to contribute to AMDVLK? Is it even possible for anyone outside AMD to contribute to AMDVLK at the moment?

IIRC, someone (most likely bridgman, sorry if that's wrong) said, they were accepting outside contributions. Unfortunately, the whole situation is slightly more complicated since due to proprietary windows bits, the AMDVLK tree is split making outside contributions somewhat harder - at least, that is what has been reiterated over and over again. On the other hand, AMD will understandably hold on to their cross-platform driver since they have to maintain it for windows anyway. Also, they can never relinquish control about releases or risk their code being rejected because their hardware enablement needs to be available when new hardware is released. So, going all Mesa simply isn't an option.
At any rate, having two relatively mature open source drivers is great progress and was mostly unthinkable even a few years ago. And while they are not entirely joining efforts, many components such as the kernel driver and the LLVM-backend are shared such that progress in those components helps both drivers. IMHO, what is more wasteful is that software developers have to/should test both drivers and in the best case contribute feedback and patches to both. However, that is not what we are seeing and due to obvious reasons not very economical for them. I am very interested to see how this entire matter will develop in the future.

[smitty3268]

The initial intentions were good and there was void at the beginning that needed to be filled. Now it's just about egos and tribalism.

That seems rather unnecessarily insulting, given that there are IMO some pretty reasonable concerns about the contribution process and distribution of amdvlk. And it's obviously tough to just abandon something you've worked hard on until you can really show it to be inferior - imagine throwing away radeonsi at this point in favor of a newly open sourced fglrx, for example.

Not to mention the fact that to date, radv has provided faster hardware support for every new card AMD has released than amdvlk. I realize bridgman keeps saying that next time it will be better, but we've been hearing that for a long time now and it hasn't happened yet...

[jrch2k8]

The initial intentions were good and there was void at the beginning that needed to be filled. Now it's just about egos and tribalism.

Not sure which group are you talking about here(i will assume AMDVLK team not Mesa) but i do believe strongly that RADV is the superior approach for Linux at least, because:

1.) IT JUST WORKS with pretty much any GCN card under the sun, so far i use it daily with Cape Verde, TAHITI, Kaveri, Kabini, 8250m and from several reports and youtubers i do follow for DXVK POLARIS works like a freaking charm leaving only VEGA on the no there yet category.

2.) It uses NIR and shares a lot of code with Intel's ANV, which overtime is a better solution simply because NIR will always get more eyes on it hence optimizations and fixes.

3.) Compatibility, i tried AMDVLK 3 times and is a lottery on which GPU may work and what application may work, this last release kinda works on TAHITI but breaks to hell DXVK, previous release simply hanged the GPU with MPV (i use super resolution shaders), any GTK4 vulkan test so far is insta GPU hang (beats me why), RADV is all peachy

4.) Adaptability, RADV has proved to improve and adapt really fast be with extension(like transform feedback and the upcoming subgroups) or hardware glitches and bugs whereas AMDVLK is kinda in the "lets hope" situation

5.) OpenGL compatibility, giving RadeonSI is going nicely ahead with a NIR backend(which i've been using for a while now, i think is stable enough to be default but i maybe missing something of course you guys know better) and SPIRV integration is close(from what i can gather on the replies to the patches so far on patchworks), i think RADV will bring proper OpenGL 4.6 interaction way way before AMDVLK/Pro stack will.

Now i'm not going as far as to say we should only have one because i simply know better and both codebases are not even similar enough to bother trying it, i also understand AMDVLK will live on simply because is a code dump from the Windows driver and it will probably be a better solution(compared to RADV) for the closed source/ Workstation drivers.

I think you guys can avoid this kind of threads from non - technically versed people by simply branding AMDVLK better to something like AMDVLK-PRO or AMDVLK-WS or something that implies is not meant as a replacement like you do with OpenGL already because non tech people wrongly assume that all developers in the RADV team have to actually stop working on it to go and fix AMDVLK and vice versa where in reality AMDVLK team prolly is not composed or even aware of RADV team and code and vice versa(i do get devs on each team can check some functionality on the other and get ideas to bring that functionality to its own driver but i don't consider that a waste of resources)

[IreMinMon]

A few things:
1. Cooperation is better than competition.
2. Since the closed-source drivers are anti-cooperation, that's where competition is necessary, and a good thing.
3. With proper cooperation, everyone would know what the best achievable implementation would be.
4. IIRC, RADV copied a lot of code from amdvlk. Clearly, amdvlk has a good implementation.

Afaik, both AMDVLK and RADV are opensource, so they could at any point copy the code over to their driver. This is competition + collaboration. And is imho very good for end user.