RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

[agd5f]

The software rasterizers: one is the legacy single-threaded reference implementation that predates Gallium (softwarepipe), one is a recent rewrite which was supposed to replace the former one (llvmpipe) but didn't get there due to resistance to llvm and the last is pretty much Intel-only (both support and use) - of all 3, the most that "normal users" see is llvmpipe as default fallback when no hardware acceleration is available - that's how most current distros are set up, since llvmpipe is the most common fallback for major compositing desktops (Gnome3, Kde Plasma and Unity).

If you count swrast, there are actually 4 software rasterizers in Mesa (one legacy mesa (swrast) and 3 gallium (swr, softpipe, llvmpipe)).

And when I say it's unusable, please remind me whether games support Mesa or AMDGPU-PRO on AMD hardware? What driver AMD developers recommend for gaming?

Most games right now are OpenGL and for OpenGL we recommend the open source OpenGL driver. It's focused more on gaming while the closed source OpenGL driver is focused on workstation.

Mesa all the way. And the only AMD-compatible Vulkan driver currently shipping in Mesa is radv, one year after Vulkan 1.0 came out.

I'm not even considering how installing AMDGPU-PRO is a pain in the butt: if you're not on Ubuntu 16.04 LTS using the original 4.4 kernel, the installer craps out (command-line only - you've lost 90% of users there, and lucky you're on Linux, on Windows you'd have lost 99.999%). Never mind using SteamOS, Fedora, Suse, Mint,ElementaryOS or whatever.

Currently only enterprise distros are supported by the pro stack. That's why it's not working on arbitrary distros. Moreover, the only reason the vulkan driver is bundled with the pro driver is because the extra kernel bits needed for it can't go upstream yet because the only user is closed source. Once it gets open sourced, all those changes can land upstream.

[smitty3268]

You're missing the key point though... the only reason the Vulkan driver can't work on an upstream kernel is because it is not open source and so kernel driver functionality required only for the Vulkan driver is not upstreamable. Once the code is opened up then it will be able to run on any upstream kernel.

Unless that's changing in the next couple months, then it's you who's missing the key point, not me.

[smitty3268]

Just about all Linux OEM pre-loads are on enterprise distros.

But how many people using OEM pre-loads are using a Vulkan driver?

The intersection of that Venn diagram seems small.

I get that it makes sense for the pro drivers to target that market for OpenGL, but Vulkan?

[bridgman]

Unless that's changing in the next couple months, then it's you who's missing the key point, not me.

Yeah, you guys are going to have fun writing snarky comments if radv catches up with features & performance before our driver gets open sourced, but...

(a) if we simply stopped work on it the criticism would probably be even worse ("wah wah, AMD lied and never intended to open source the driver, it's a good thing Dave worked on radv or we would have all been screwed by AMD"), and...

(b) radv doesn't give us what our Vulkan driver does, which is a direct path for leveraging closed-source development work into the all-open stack.

[bridgman]

But how many people using OEM pre-loads are using a Vulkan driver?
The intersection of that Venn diagram seems small.

Agreed (although I'm sure someone somewhere is gaming on a big-iron RHEL server as we speak), but remember that initially we were also pushing the -PRO driver out as a stopgap solution for consumer users, in order to get (a) fast OpenGL before the performance work we were doing on Mesa GL showed results and (b) Vulkan before the open sourcing effort showed results.

[oooverclocker]

I think there shouldn't be unjust criticism but it would make sense to set the priority quite high when the work on Vega is done and DC is in the Kernel. With Dota 2 and The Talos Principle it wasn't really necessary to have well performing Vulkan drivers. But with the Dolphin Emulator and now Mad Max it looks like one could really profit a lot and these images of an 980 Ti running much faster vs. a Fury not running faster also arrive in articles of gaming magazines not having that much to do with Linux. And they don't know what RADV is and mention that AMD and Intel GPUs aren't supported anyway.

So to be very honest, from the perspective of AMD there shouldn't be too many more games showing AMD cards being unable to benefit from the Vulkan implementation on Linux while the Nvidia driver works well.
In the end I don't know the agenda and were it fits in... but I hope it will get a higher priority with a growing number of Vulkan titles.

[duby229]

Yeah, you guys are going to have fun writing snarky comments if radv catches up with features & performance before our driver gets open sourced, but...

(a) if we simply stopped work on it the criticism would probably be even worse ("wah wah, AMD lied and never intended to open source the driver, it's a good thing Dave worked on radv or we would have all been screwed by AMD"), and...

(b) radv doesn't give us what our Vulkan driver does, which is a direct path for leveraging closed-source development work into the all-open stack.

On a) That's just the nature of marketing. You'll always have someone complaining. Right now it's AMD's fanboys complaining and their competitors fanboys cheering them on. On b) No of course not, radv gives you something waaaay better than that. A community supported driver with open source code sharing within a common framework.

[ernstp]

bridgman What _are_ the kernel dependencies of the closed source Vulkan driver?
Are they in amd-staging-4.9 ?
edit: or perhaps that's more of a question for agd5f

[schmidtbag]

On a) That's just the nature of marketing. You'll always have someone complaining. Right now it's AMD's fanboys complaining and their competitors fanboys cheering them on.

Yes, there will always be someone who complains, but your overall statement is a bit too generalized. For starters, Nvidia fanboys also have to deal with closed drivers, so their cheers would be a bit hypocritical. Meanwhile, Intel doesn't exactly have any GPU hardware worth bragging about.
I, for one, am happy that there is an AMD-supplied Vulkan driver that, to my knowledge, is fully compliant and stable. Sure, I think we'd all be a lot happier if it was open-sourced a long time ago, but at least it was supplied early on. For me personally, I'd rather it leave experimental status on GCN 1.0-1.1 GPUs before it gets open-sourced.

On b) No of course not, radv gives you something waaaay better than that. A community supported driver with open source code sharing within a common framework.

A community is only as good as its members/contributors. Take a hard look at all the open-source GPU drivers out there that don't have a corporation backing them. Most of them struggling to keep up (especially on ARM), to put it lightly. Open-sourcing drivers doesn't magically make them better. It will not guarantee somebody will step up and make something better. GPUs are complex beasts, and most people who volunteer for the good of the community just don't have the knowledge, time, or skills to handle modern GPUs.

My point is, if AMD open-sourced these Vulkan drivers from the very beginning, we likely wouldn't have seen much (if anything) change from 3rd party devs. On the other hand... Arlie could've devoted his time to something else (not that he couldn't have done that anyway *sigh*).

I'd like to clarify - I see no reason not to open-source these drivers and I do absolutely see it as a good thing that in the long term will be helpful. But, as long as these drivers work as advertised and will be open-sourced, just be patient and thankful you have them at all.

[duby229]

Yes, there will always be someone who complains, but your overall statement is a bit too generalized. For starters, Nvidia fanboys also have to deal with closed drivers, so their cheers would be a bit hypocritical. Meanwhile, Intel doesn't exactly have any GPU hardware worth bragging about.
I, for one, am happy that there is an AMD-supplied Vulkan driver that, to my knowledge, is fully compliant and stable. Sure, I think we'd all be a lot happier if it was open-sourced a long time ago, but at least it was supplied early on. For me personally, I'd rather it leave experimental status on GCN 1.0-1.1 GPUs before it gets open-sourced.

So this brings up a fairly complicated topic. Two of them in fact. And they're not particularly related. The first thing is that we are both pretty familiar with other members of this forum. We've come to be familiar with many other peoples opinions on matters. It's not that difficult for you or I to recognize an AMD fan over an nVidia fan. Maybe that's not our place, but we are humans and we have the ability to recognize patterns among people.

The second thing is that it really isn't so much GCN1.0 and GCN1.1 support that is experimental. Rather it's that the earliest GCN parts used an ASIC that was very similar to the ASIC used by the VLIW4 parts. To support those ASICs required initially porting support for them from r600. Now that support needs to be duplicated further into amdgpu. At least that is how I come to understand the difficulty.

A community is only as good as its members/contributors. Take a hard look at all the open-source GPU drivers out there that don't have a corporation backing them. Most of them struggling to keep up (especially on ARM), to put it lightly. Open-sourcing drivers doesn't magically make them better. It will not guarantee somebody will step up and make something better. GPUs are complex beasts, and most people who volunteer for the good of the community just don't have the knowledge, time, or skills to handle modern GPUs.

I'd like to clarify - I see no reason not to open-source these drivers, but as long as these drivers work as advertised and will be open-sourced, just be patient and thankful you have them at all.

Exceptional individuals do in fact exist. What you just proposed is essentially the same thing as eliminating the environment in which exceptional individuals can flourish.I don't have to thank them for that. It's just plain wrong. Look at beigenet as a perfect example of how an open source project can effectively be the exact same thing as proprietary.