RadeonSI OpenGL vs. RADV Vulkan Performance For Mad Max

[mitch074]

In my case, the most annoying part is that AMDGPU-PRO's performance and stability leave much to be desired in OpenGL, prompting me to use Mesa instead and yes, a recent kernel, as OpenGL-using apps are far more numerous than Vulkan ones. However, installing the closed source Vulkan driver is dependent upon installing AMDGPU-PRO - which can only be done on Ubuntu 16.04's original release 4.4 kernel with AMD's current driver installer (which is pretty much building upstream amdgpu drm/kms code and then loading closed source userspace modules). But my RX480 doesn't work with linux 4.4.
So, if I want to switch between Mesa and AMDGPU-PRO, I need to change both kernel and graphics stack - so it's a reboot every time, compared with merely changing the stack which requires only an X restart (for now - Wayland is supposed to avoid even that).
Isn't it possible to use AMDVLK along with Mesa on a recent mainline kernel? I'm not asking for a separate installer, not even a script, but a list of steps to follow - say, install Oibaf (which doesn't include RADV), unpack AMDGPU-PRO and select this or that package to install, use dpkg to build this or that version for the kernel's module, and start the app with this or that setting.
Ideally, a separate installer would still be nice provided AMDVLK can be shipped as standalone.

[M@yeulC]

You mean something like this

No, my first impression was that the screenshots contained huge story spoilers. The benchmark names, too. Ugh... I have to finish this game. I just tried not to think about what I saw in the images.
Unfortunately, I think I would need a new graphics card to have better performance, it became sluggish around gastown with my 6870.

[marek]

I don't see what the issue is with Ubuntu 16.04.2. Ubuntu allows installing previous kernel versions from their package repository. You don't have to use the latest one.

[ernstp]

That is easy to fix - Michael just needs to start running tests on the amdgpu-pro Vulkan driver again rather than acting as if radv is the only Vulkan driver for AMD hardware. If we were not working on open sourcing our Vulkan driver it would be easier to understand because radv would be the only option for open source stack users now and forever, but the current state basically punishes us for working on what we said we would do.

That's because amdgpu-pro is such a pain to install and use. It's almost like it's it abandoned already. You can't even install it on a new Ubuntu 16.04.2 installation, you need to roll back to an old kernel. You have no idea if and when bugs are fixed, things break randomly between releases, etc etc.. it's all been written before. We're soon at 3 months since the last release.

[marek]

I also think that RADV is a useful and interesting project, but it's not AMD's Vulkan driver.

[FireBurn]

No holdup, it's just a big pile of work and "rewriting to eliminate things you can't expose publicly" is not something that can be done in a public tree.

I kinda thought with the vulkan driver being written from scratch you guys wouldn't have this issue this time

[bridgman]

Exactly. The apprehension is that man hours are wasted because two teams are working on the same thing. Valve doesn't have a Vulkan driver to work on/with other than RADV etc.

Already having the code in your hands, your company could perhaps have tried to contribute to the project called "RADV" your code successively in a mostly platform independent form. Kind of leading by contributing. Which might have led to very few differences so you could have implemented RADV mostly in your drivers for other platforms. (Theoretical ideas)

Sure, but we don't just have engineers sitting around doing nothing who can go and work on something new just because someone else started a project that overlaps with what we are already doing. We would have to pull people off existing projects, and right now there aren't any projects we can afford to back-burner.

Now it seems too late and the chance to share the code would be to open the driver performing significantly better than RADV. And this time is running and I also don't like to see too many people investing time in RADV that gets obsolete right before reaching their goal.

Do you agree that investment in radv is not under our control ? The fact that it is a good and useful project (as it is IMO) does not make us responsible for duplication of effort.

I know it seems simple to say "just spend a big pile of money and hire new developers to work on open sourcing the driver more quickly" but (a) money was not actually lying around in piles last time I looked, (b) hiring new developers and bringing them up to speed takes time, and (c) finding/building developers who can work effectively across both open source and closed source code bases and earn the support of both sets of teams takes the longest of all.

Vega is also the last big milestone on a long list of impressively, successfully implemented tasks from what I can see in my mind's eye ... Although I really hope that there are many creative minds who have been activated. But I guess the remaining bigger tasks are mostly on the open source side, and keeping the work up in other places. Not having to deal with any drivers anymore forever is one of the biggest advantages any GPU customer can have in comparison to Nvidia. So providing the drivers would lead to complementary effects increasing the market share of Linux and at the same time making your GPUs more attractive than your competition's, which leads to more contribution to optimize them. Accelerating the future can sometimes have a significant monetary value.

I don't understand your "never having to deal with any drivers any more forever" comment, are you just talking about drivers being upstream ? If so, that is actually *not* enough to insulate customers from having to think about drivers, since the final launch-ready drivers are never going to be in a six-month-old distro relase even if we push working code upstream long before launch. There are always going to be late-arriving games, bugs/changes in other drivers etc...

I don't actually understand your "the remaining bigger tasks are on the open source side" comment either, now that I think about it, although there are several possibilities.

When several parties had perhaps an influence of 1% (as an example) in the next year on the OS market by improving the ease of use and increasing AAA games on Linux and in contrary to Windows 66% of Linux users would buy your GPUs instead of Nvidias, because everything about the drivers would work immediately and forever, you could sell 0.33% more GPUs in the following years. It might not sound much, but it's a big value that would be definitely worth something and it should usually increase when people tell others about it.

In fairness, everyone talks about the potential benefits but nobody seems to want to talk about the costs. It's like everyone assumes we have cash spilling out the door and developers waiting around for a project to work on. Everything is about opportunity cost for a while longer, like it or not.

And it would stop graphs of benchmarks showing Nvidia with proprietary vs. AMD with RADV- drivers also having a durable subliminal negative impact. Especially when they're quoted by people who don't have any idea about the current state and this happens more and more, especially by mainly Windows oriented magazines who also included Phoronix in their sources.

That is easy to fix - Michael just needs to start running tests on the amdgpu-pro Vulkan driver again rather than acting as if radv is the only Vulkan driver for AMD hardware. If we were not working on open sourcing our Vulkan driver it would be easier to understand because radv would be the only option for open source stack users now and forever, but the current state basically punishes us for working on what we said we would do.

Of course I can't look on your schedules and I do absolutely venerate what happened so far but I just wanted to give you some ideas why a soon open sourced Vulkan driver on Linux can be worthwhile, not only for users and especially when there is an appropriate GPU lineup it would be very helpful when it had full support as soon as possible without installing additional things, especially when the first part of Star Citizen launches.

We understand that it is worthwhile and have had developers working on it for a year or more... but you may also be mixing "open sourced" with "working with the upstream open source stack". Realistically you are going to have to install/update drivers to get the best use from graphics hardware for a while longer, at least as long as new games and new API versions are arriving on a regular basis, so temporarily installing a binary Vulkan driver (knowing that it is being open sourced) would not be additional work.

[oooverclocker]

radv has filled that gap more than we should have allowed it to, but we can't go back and change that now.

Exactly. The apprehension is that man hours are wasted because two teams are working on the same thing. Valve doesn't have a Vulkan driver to work on/with other than RADV etc.
Already having the code in your hands, your company could perhaps have tried to contribute to the project called "RADV" your code successively in a mostly platform independent form. Kind of leading by contributing. Which might have led to very few differences so you could have implemented RADV mostly in your drivers for other platforms. (Theoretical ideas)

Now it seems too late and the chance to share the code would be to open the driver performing significantly better than RADV. And this time is running and I also don't like to see too many people investing time in RADV that gets obsolete right before reaching their goal.

Vega is also the last big milestone on a long list of impressively, successfully implemented tasks from what I can see in my mind's eye ... Although I really hope that there are many creative minds who have been activated. But I guess the remaining bigger tasks are mostly on the open source side, and keeping the work up in other places. Not having to deal with any drivers anymore forever is one of the biggest advantages any GPU customer can have in comparison to Nvidia. So providing the drivers would lead to complementary effects increasing the market share of Linux and at the same time making your GPUs more attractive than your competition's, which leads to more contribution to optimize them.
Accelerating the future can sometimes have a significant monetary value.

When several parties had perhaps an influence of 1% (as an example) in the next year on the OS market by improving the ease of use and increasing AAA games on Linux and in contrary to Windows 66% of Linux users would buy your GPUs instead of Nvidias, because everything about the drivers would work immediately and forever, you could sell 0.33% more GPUs in the following years. It might not sound much, but it's a big value that would be definitely worth something and it should usually increase when people tell others about it. And it would stop graphs of benchmarks showing Nvidia with proprietary vs. AMD with RADV- drivers also having a durable subliminal negative impact. Especially when they're quoted by people who don't have any idea about the current state and this happens more and more, especially by mainly Windows oriented magazines who also included Phoronix in their sources.

Of course I can't look on your schedules and I do absolutely venerate what happened so far but I just wanted to give you some ideas why a soon open sourced Vulkan driver on Linux can be worthwhile, not only for users and especially when there is an appropriate GPU lineup it would be very helpful when it had full support as soon as possible without installing additional things, especially when the first part of Star Citizen launches.

[bridgman]

Thanks for writing that. I was in the process of writing something similar, hopefully equally gracious.

One of the real challenges we have as more teams get involved with the open source drivers is that each new team "starts from further away" in terms of understanding the benefits of working in a community code base. The downsides seem larger and the benefits seem smaller or even non-existent, so you are not going to see the immediate "hell yeah let's drop everything we are doing and start over" decisions you might hope for; there is going to be a learning curve. In fairness, even with full understanding it doesn't automatically make sense to switch everything over to a community-centric model.

What I'm afraid of happening right now is that AMD is beginning to change its strategy to be more independent from other upstream sources. Maybe that is unfounded, I'm not sure yet.

It is a valid concern, but IMO what you are seeing is not a deliberate shift in strategy, just the natural consequence of new teams starting to get involved in the open source driver efforts. Every additional team is going to have to go through this - all I can ask is "be nice and don't scare them away".

Despite all the abuse heaped on the DAL team, they did write new code from scratch, used it for Linux first, and tried really hard to make it right for the Linux kernel while maintaining the ability to share code with other platforms. What they were not able to do in real time was to anticipate where the drm framework would be by the time they finished and have everything aligned when the first code was ready. Atomic modesetting didn't really exist when the project was started (I think it was being discussed but hadn't been really adopted yet) and so the idea of having a separate, more advanced interface wrapping the code didn't seem like such a bad thing. It *became* a bad thing about 1/2 way through the project, unfortunately, but those things are going to happen.

We are going to have similar challenges on the Vulkan side. If radv had not existed the Vulkan team might have seen making the binary driver work with upstream Linux kernel drivers as a higher priority (and IMO it is probably still worth doing even today) and so the whole "radv is the only option for someone using the open source stack" issue would never have come up.

It seems likely that radv is going to mature around the same time that we get an open source version of our Vulkan driver out in the wild, which is going to be awkward, but realistically the only other option would have been for us to stop work on something we had already said we would do *before* a good alternative existed.

The initial code sharing environment is going to favour sharing code between Mesa GL and Mesa Vulkan (radv) rather than between Mesa GL and our Vulkan driver, but we are building some of that same sharing model into our own Vulkan driver (eg using the same shader compiler) and are continuing to support the "open sourcing our driver" initiative because there do seem like some good opportunities for building future Mesa GL HW support on top of the same HW layer code we use for Vulkan, which would mean another increase in our ability to leverage code written for other platforms and APIs in the Linux world.

In the end it's all a set of compromises - writing separate driver code based on community projects is always going to be more attractive in some ways, but unless we can fund really big teams to work on Linux-only drivers there is always going to be an aspect of "yeah but it should be happening faster" to everything we do for Linux. Sharing code between platforms and APIs allows more teams to contribute to Linux deliverables, but there is always a downside in the sense that sharing code brings the risk of dragging the code structure away from what a pure community-only approach would choose.

In the case of OpenGL we felt that going with Mesa as the primary consumer driver made sense because there was relatively little overlap in priorities between our internal OpenGL teams (who generally focus on workstation apps) and consumer requirements (OpenGL gaming on Windows is not big these days), so there was not as much benefit to be had from code sharing as it might have initially appeared. Vulkan will probably get picked up in the workstation space eventually, but at the moment the focus is almost entirely gaming and VR so there is more potential overlap and more potential benefit from sharing driver code with other OSes even if that sharing is only visible internally to AMD.

On the other hand there are also some additional factors which make open source more important than a year or two ago - developer houses like Feral who have invested enough in learning Mesa internals to start seeing real benefit (and even contributing fixes back), and companies like Valve who are investing in VR but who need either an open source driver or a sufficiently collaborative environment around the closed source driver in order for their developers to work.

So yeah, the timing is inconvenient with radv as an alternative, but until we can start pushing code out in public and are able to discuss new code-sharing models it's too soon to say for sure what the right plan would have been. I do think we left a gap by not finding a way to make the Vulkan binaries work with upstream kernel drivers, and radv has filled that gap more than we should have allowed it to, but we can't go back and change that now.

[duby229]

All of them, and more importantly games which have not yet been announced as well. They can also do that on radv today but that was not possible back when the most important decisions were being made.

I guess you typed "oss" in there a couple of times by accident, since open vs closed would not have been a factor for major game developers making decisions 6-12 months ago - or are you saying that game developers completely ignore NVidia ?.


They *are* the same driver (along with other APIs and other platforms). If you keep ignoring this point it will continue to be easy to draw different conclusions, however those conclusions will also continue to be incorrect.


Yep, that's what I said about "turning the code sharing model around". The goal would be to share with other Linux drivers *and* with other platforms.


You accidentally typed "oss" in there again, when the open-ness would not have had any relevance back when major game studios were making API decisions for their Windows games. Maybe there is something wrong with your keyboard, a rogue macro or something ?


I don't understand what is so hard about this. It's the difference between writing one driver and writing two drivers (or three actually, since we currently have to write new code for Mesa GL as well with every new HW generation.


Then why did you keep saying "open source" if you meant "works with the upstream kernel driver" ? We could have saved a bunch of time and thread space if you had said "works with the upstream kernel driver" from the start. In the end I had to ignore your words and guess at what you meant.

Ok. Someone I know thinks I've been too upset, so maybe I should apologize to you guys for that. My bad, I am sorry for that.

I never want to underestimate the amount of effort you guys put. Honestly I think AMD has done some of the most fantastic open source development for hardware support I've ever seen. That's why I am a fan and I try to use AMD as much as possible. What I'm afraid of happening right now is that AMD is beginning to change its strategy to be more independent from other upstream sources. Maybe that is unfounded, I'm not sure yet. I hope that whatever open source code you eventually release will be beneficial to the whole graphics stack. That was the awesome thing about Gallium I thought. It was that it had the potential to bring together graphics driver developers for different kinds of hardware together to works towards common goals. That was my impression anyway as a bystander.

Anyway maybe none of that matters. I just hope AMD continues sharing its code in a way that keeps it as close to the community as it has been. I'm afraid of losing that.