Testing RADV's Out-of-Order Rasterization Vulkan Performance

[GruenSein]

It would be better late than never, if they combined efforts.

You can only reasonably mean combining efforts on AMDVLK. Please don't make people reiterate why AMD needs their own cross platform code base.

[nanonyme]

But in the case of Vulkan it's a shame that they don't combine their efforts with the AMD devs. Would be nice if all the smart people were contributing to the same driver (I don't mind either RadV or amdvlk).

But I understand the reality that amdvlk codebase is needed for windows, and that the community including Red Hat, Valve etc had to act rather than wait for AMD.

Not reasonable to contribute on amdvlk without having an NDA on AMD so you see unpublished sources. The code pushes are too large and too seldom

[R41N3R]

Combining the Vulkan drivers wouldn't be beneficial like in the OpenGL world. Actually I like that we have for AMD two great Vulkan drivers that benefit from each other and compete on a performance level. And then there is the Nir support from RADV that helps to enable OpenGL 4.6 and maybe replaces TGSI at some point. So I can only see advantages.

[Shevchen]

Nice results, esp. as those are games which are not written from the core up for Vulkan. Results on games designed for Vulkan should end up with even bigger performance leaps. Every little bit helps.

[nanonyme]

Combining the Vulkan drivers wouldn't be beneficial like in the OpenGL world. Actually I like that we have for AMD two great Vulkan drivers that benefit from each other and compete on a performance level. And then there is the Nir support from RADV that helps to enable OpenGL 4.6 and maybe replaces TGSI at some point. So I can only see advantages.

Yeah, and a lot of heavy lifting happens in kernel and LLVM anyway and gets shared out of the box