RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

[bridgman]

AMD is supposed to have the superior architecture, especially when doing Vulkan stuff.
So, I'm wondering, what are those "things you can't expose publicly" exactly, AMD hardware details or 3rd party code/IP ?

Pretty much all third party IP from the non-Linux OSes the code also supports. I don't think hardware details have been an issue yet.

Also, what's the planning for this AMD opensource Vulkan driver ?
Will we see it when VEGA is released ?

Unfortunately it has to be one of those "you'll see it when it's safe to release".

Removing sensitive third party information is not something that can be done in public, for obvious reasons.

[bridgman]

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.

Isn't Beignet more of an example of what can happen when a big company puts resources into a project ?

[duby229]

Isn't Beignet more of an example of what can happen when a big company puts resources into a project ?

Is there such a thing as a flabbergasted smiley?

[haagch]

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.

Which bits exactly are that? Everything I tried so far with the closed source Vulkan driver works on the mainline kernel. Only libdrm with various patches from the mailing list is needed... I only noticed that performance isn't as good as I expected e.g. in The Talos Principle. Are there missing kernel bits that would make it perform better?

[bridgman]

Is there such a thing as a flabbergasted smiley?

I have never found a good one.

My impression was that most of the developers working on Beignet were Intel employees - do you disagree ? Or am I missing something different ?

[schmidtbag]

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.

Agreed. Some of the nouveau devs blow my mind sometimes. And as we both know, RADV made tremendous progress in a relatively short time. But I am not proposing that AMD keeps their drivers closed. Again, I want to stress that I do want these drivers open-sourced. However, AMD released them as closed for whatever upper-management reasoning they had. Perhaps they wanted to polish it themselves before they were flooded with commits elsewhere that may contradict other plans. Many people look at these closed drivers as though they will remain that way forever, and that they should be avoided simply by principle. It's fine if that's someone's personal opinion, but my opinion does not agree with that, and I also feel that AMD devs should not be ridiculed because of it (I'm not suggesting you are, I'm just generalizing).

I'd much rather take something than nothing. I prefer functionality, performance, and compliance over available source code. Of course, there is absolutely nothing stating you can't have both. But sometimes you just have to take what you can get. Sometimes life isn't fair. We can tell Nvidia "f*** you!" because they have proved to make life more difficult for some Linux devs. But on the other hand, if they didn't provide those drivers and didn't change their involvement with nouveau, Nvidia GPUs just wouldn't be a viable option for Linux. We may not have ever seen the availability of Steam as a result.

[oooverclocker]

The big problem of all this is that when you invest hours to implement a Vulkan feature in RADV and it would take ages to get on a level near the proprietary drivers, as soon as AMD open sources their driver all your efforts were useless when it's faster. And it's even good that way because that means everyone would quickly support only one driver. So for the open source development optimizing RadeonSI, reducing overhead etc. has the highest priority and I guess there will be enough optional features left to be implemented and things to be optimized for at least this year and parts of the year after until the commitments slow down.

But this means on the other hand that RADV will evolve slowly, and it isn't even nearly feature complete so the process of optimization will take a lot of time. And when I read that perhaps it would be even faster than the closed source implementation when it's open sourced... from how it evolved in a whole year that sound like a very long time. Although such a low level API should usually be faster to implement than the old ones...
It's still important to have another ace in the hole for the case that something goes wrong with the open sourcing process though.

Using the proprietary Vulkan driver and OpenCL implementation with RadeonSI might be an option if you're able to do it and interested enough but as long as the transition process hasn't been finished it reduces the attractiveness of AMD GPUs for Linux users significantly. When Ubuntu 17.04 comes out I could finally say: "Take an AMD GPU so everything works immediately or will be implemented in a short time." Now the poor RADV performance crosses the line because Vulkan is becoming important. I would still recommend an AMD card because I believe it's the better choice but it is harder to justify. Because all options that are left to get the missing performance are equal to buying an Nvidia card instead and installing the proprietary drivers.

I really hope the next months will prove my estimations wrong.

[Mystro256]

Agreed. Some of the nouveau devs blow my mind sometimes. And as we both know, RADV made tremendous progress in a relatively short time. But I am not proposing that AMD keeps their drivers closed. Again, I want to stress that I do want these drivers open-sourced. However, AMD released them as closed for whatever upper-management reasoning they had. Perhaps they wanted to polish it themselves before they were flooded with commits elsewhere that may contradict other plans.

If you're referring to Vulkan, AFAIK there are third party IP issues blocking the release of code; i.e. it would take time to remove unreleasable code and approve it before releasing things openly.

[ossuser]

Pretty much all third party IP from the non-Linux OSes the code also supports.
...

So, if I understand right, if the code parts written by Microsoft/Sony are removed there will be an AMD open source Vulkan driver ?

[smitty3268]

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.

Making snarky comments is fun, though.

Anyway, I am just growing increasingly worried about the AMD Vulkan driver. I hope you don't think that making it open source is a magical fix for everything and that's all that needs to be done to make it successful.

The radeonsi drivers are a great improvement over the old fglrx stack, but just being OSS is not what put it in the position it's at today. You need to build a community around the project. You need it to be easy to install and run everywhere. It needs to be relatively bugfree and stable. You need all the other stuff the Mesa project has provided for radeonsi, and I'm not convinced AMD really gets that. You need all that PLUS a good reason for people to switch away from the current driver - which for the moment would be performance, but who knows how long/if that will last.

If you just throw the code over the wall and say it's OSS, and think that's going to replace radv I think you're going to be disappointed.

Really hope I'm just being pessimistic here, but that's where I'm at right now re: AMD's vulkan driver.

Anyway, I lasted a whole year with no driver before I started making snarky comments, and if you ever thought people's patience would last more than a year you were very wrong. 1 year was right when people started getting antsy/snarky about the missing r9 285 driver support too. I know you'll never do it, but you'd do yourself a big favor to just throw out a rough timeline. "We're hoping for Q2 2018 launch, but no promises" would at least cause people to give you another 6-9 months before the questions start up again.