Mesa's RADV Vulkan Driver Holds A Narrowing Lead Over AMDVLK With Ubuntu 21.10 On Wayland

[tajjada]

As a graphics developer (still very much learning / a noob, but i think i can call myself one) I feel very torn about this dual-driver situation.

They have such a mixed feature set.

AMD's Radeon GPU Profiler, which is a fantastic dev tool, for understanding how the GPU works and what it is doing, only works with AMDVLK. I need AMDVLK if i want good dev tools. AMDVLK also exposes separate vulkan queues for the DMA engine / memory transfers. RADV does not. AMDVLK is also the same driver as on Windows, which helps with having realistic expectations for how things work cross-platform.

Now RADV has mesh shaders. IIRC it also had some other features that AMDVLK is missing. And often better performance.

Luckily, Vulkan makes it easy to have both drivers installed and switch between them easily.

[Quackdoc]

both RADV and AMDVLK have their advantages. and considering that they are both userspace driver that can co-exist, they were probably using both drivers depending on the game, I doubt setting up a per-game profile is much of an issue is there any evidence to suggest they didn't use both? and exclusively used AMDVLK?

[mphuZ]

mphuZ
Google was foolish enough to settle on it for Stadia instead of choosing the objectively superior RADV solution that would have allowed them to actually improve the performance of

The best for whom? For you or game developers?
Are you ready to commit to supporting AMD graphics cards programmatically? All major platforms enjoy the full support of the hardware manufacturer (except Valve) and so far nothing bad has come of it.

[skeevy420]

Not only that, but POLARIS was sold as AMDs low to medium end discrete architecture for a very long time. You can still buy new RX 580s on Amazon! Personally, value has to improve a lot for me to upgrade from my POLARIS card for the foreseeable future. Sure, I'd love a 6900 XT, if someone want to buy me one!

I am concerned POLARIS is being neglected now by AMD, even within Mesa. The lack of modifier support for GFX8 is extremely problematic for direct scanout, and prevents the use of Vulkan compositors.

I feel like they're stretched thin so they focus as much as possible on their current gen GPUs and everything else gets pushed to the back burner. It really seemed that way during the initial Radeon>AMDGPU bringup when some GPUs like the 290x had lots of people reporting issues that never got fixed...most every premium card from before Polaris is in the same boat. Vega would probably be in that boat if it weren't for all the Vega APUs.

[skeevy420]

Well yeah.. I understand the current GPU situation very well. My point is that the QA of PAL drivers (DX12 and AMDVLK) seems lacking on Polaris, even though it's the most popular AMD architecture, so AMD should put more effort into it. I mean I haven't even heard about cases when Vulkan extensions just break in any other Vulkan driver.

Can't say I disagree there. Frankly, I think they maintain too much and they're not the best open source stewards. By that I mean things like how Intel doesn't have 3 Vulkan drivers and how they do giant ass code dumps instead of individual commits.

I'd shit a brick if AMD contributed AOCC/their LLVM tweaks to Intel's oneAPI. (The joke is it can't technically be "oneAPI" if AMD has AOCC)

[s_j_newbury]

Because Polaris was the last AMD GPU we could buy before Crypto and NFT drove prices to ridiculous levels. If you're like me and $200-300 for an RX 580 was a big purchase, you ain't gonna spend $500-600 on a 6600XT...pretty much the one GPU they've released that can be considered to be the upgrade path for the cheap-asses who stick to mid-range or lower cards.

Not only that, but POLARIS was sold as AMDs low to medium end discrete architecture for a very long time. You can still buy new RX 580s on Amazon! Personally, value has to improve a lot for me to upgrade from my POLARIS card for the foreseeable future. Sure, I'd love a 6900 XT, if someone want to buy me one!

I am concerned POLARIS is being neglected now by AMD, even within Mesa. The lack of modifier support for GFX8 is extremely problematic for direct scanout, and prevents the use of Vulkan compositors.

[Linuxxx]

mphuZ

Couldn't you have used your Asperger-Syndrome to specialize in anything else other than the POS driver that is AMDVLK?

Google was foolish enough to settle on it for Stadia instead of choosing the objectively superior RADV solution that would have allowed them to actually improve the performance of their nowadays aging server-grade VEGA56 over time.

But since Stadia will most likely get abandoned in 2022 anyway (hey, it is still a Google product after all), it doesn't matter anyway.

Just too bad about all the lost manpower that could have gone into boosting RADV even further [to help the Steam Deck]...

[Seebi]

I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
With fossilize-replay from https://github.com/ValveSoftware/Fossilize
`time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
amdvlk: 115,88 secs
amdgpu-pro: 32,51 secs
radv/aco: 10,81 secs

Thanks for all these examples!

One more comment on shader caches: It *can* play a role even if no caches exist when starting the application. The key is, that compilers compile complete pipelines, but can cache shaders that are reused between pipelines (under some premises, I think the pipeline descriptor layout needs to be the same). If a game reuses a pixel or vertex shader in a lot of pipelines, caching the compilation results makes a noticeable difference

[user1]

I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
With fossilize-replay from https://github.com/ValveSoftware/Fossilize
`time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
amdvlk: 115,88 secs
amdgpu-pro: 32,51 secs
radv/aco: 10,81 secs

I didn't test shader compile time myself, but that's exactly how I felt when I tested all 3 compilers in a shader heavy DXVK game. ACO was the fastest, and Pro compiler was much closer to ACO performance than to LLVM.

[Masush5]

I would like to see a test like this: https://gist.github.com/pendingchaos...089f29a8c6aa63
As you can see, even the ACO was inferior to the proprietary compiler in this test. I want to see the actual figures.

I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
With fossilize-replay from https://github.com/ValveSoftware/Fossilize
`time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
amdvlk: 115,88 secs
amdgpu-pro: 32,51 secs
radv/aco: 10,81 secs