AMD Planning For Launch-Day Vega Open-Source & AMDGPU-PRO Support

[boltronics]

Even without Vulkan adoption, putting a lot of work into Crossfire on Linux only makes sense if the game developers/porters do the same

But currently we've got a chicken and egg problem. There seems to be a reasonable number of games on Windows that support it.

there is not much in it for them. The situation is different from a few years ago, where multiple high end cards were required to get decent frame rates (so game developers were motivated). These days a single high-end card is usually sufficient.

Even at 4K? I know most people still game at 1920x1080, but some of that would be because nobody can reasonably play at 4K right now. I know that's why I'm not using it at least.

No argument there. We need to make it easier to find & download Linux drivers. My thinking was to do less "tell us what you have" and more "here are your options, pick one, recommendations below".

That sounds great. I'm also not sure why Windows gets a category for every version, but the GNU/Linux drivers are hidden away under "Other". But anything to get rid of the multiple pages to click through and fixes for the broken/incorrect links.

I hadn't heard about issues when skipping a version, if so that's something we need to look at for sure.

Some of the package names were changed a couple of releases back IIRC, which I think was what triggered the issue for me. Maybe the upgrade failed because of my umask, and the package names were all different when upgrading which made a mess... sorry I don't remember the exact details. But I do remember wondering what a normal person would have done if they encountered such a thing.

AFAIK the installer is an intermediate step towards being more integrated with distro packaging systems but I haven't been following the plans there.

A suggestion; It would probably be easier to package, easier for the end user and ultimately more secure to use have an official AMD PPA or repository until packages can get included in Ubuntu. It doesn't even have to be hosted on LaunchPad. See the way VirtualBox and ownCloud are packaged for examples that work well.

You wouldn't even need to delete old versions from the repository, so people can pin old versions in their preferences file if needed. That's how I deploy custom packages to servers in my workplace.

Interesting point about umask; I hadn't heard about people changing it from default normally but maybe that happens more than we think. Are you suggesting we force permissions on installed files even if that disagrees with umask, or that we fail if we can't install with <umask> permissions and have the driver work ?

I think the issue was that it created directories and copied files as root without explicitly setting the permissions, so unprivileged access failed. Maybe DKIM or something was running unprivileged... not sure. I just remember having to dig around some of the contents of /var to fix permissions up. I might have had to fix up a /etc/apt/sources.list.d entry that AMD put there too? Non-privileged users should be able to read all those files to avoid apt warnings as well.

That one *is* a different people thing - this isn't about "stability vs performance" just about "raising GL level vs performance". People working on stability are still working on stability.

Cool. I've seen Marek respond to one of the kernel panic reports I was subscribed to and asking if it was still an issue, and he seems to do a bit of performance work so made that assumption. Fair enough.

Performance is not getting anything like 90% of the focus, and it never did other than in the news. Our Mesa developers (all ~2 of them) were splitting time between GL level support, bug fixes and reliability; the only change is that the time they spent on raising GL level is now going into performance, while work on bug fixes and stability is continuing.

Nice. Thanks for clarifying.

I suspect the real issue here is that performance gains are much more news-worthy than bug fixes and stability improvements.

That's true (and OTOH why I thought AMD might be more interested in working news-worthy items), although some of that is what I've gathered from freedesktop reports too - but certainly just an impression I felt rather than anything scientific.

[twriter]

Some of the package names were changed a couple of releases back IIRC, which I think was what triggered the issue for me.

Packaging was redone starting with 16.40, to support added distros (RHEL 6.x, RHEL 7.x, SLES/SLED 12sp2), to move (almost) everything to /opt to avoid conflicts with distro provide packages, and to correct dependencies. We also laid the groundwork for on-line package delivery. The goal is for installation to be as simple as:

1. Add AMD package repository
2. apt-get install amdgpu-pro

but it will probably be a few more releases before we get there.

Maybe the upgrade failed because of my umask, and the package names were all different when upgrading which made a mess... sorry I don't remember the exact details. But I do remember wondering what a normal person would have done if they encountered such a thing.

Ask their expert friend or here on the Phoronix forums. It's not easy to cover every eventuality, esp. when the packaging is in flux. Currently, the install script is conservative and attempts to remove the previous driver before installing a new one. For that, it uses the temporary package repository which, from your earlier comments, it sounds like you may have removed or the permissions may have been wrong.

A suggestion; It would probably be easier to package, easier for the end user and ultimately more secure to use have an official AMD PPA or repository until packages can get included in Ubuntu. It doesn't even have to be hosted on LaunchPad. See the way VirtualBox and ownCloud are packaged for examples that work well.

I'll check out VirtualBox and ownCloud packaging (thanks for the pointer) but it might not be as simple as you describe. As you know already, each release packages approximately 50 packages. For QA and some customers, we require installation of a consistent set produced by a full stack build from a known set of commits. For example, "apt-get install amdgpu-pro=16.60-379184" should install all ~50 packages from build 379184 and only build 379184. This is unusual and I don't know of an easy way to do it. I think we have a solution now which we're just beginning to roll out internally so we can test before releasing publicly.

Regarding inclusion of packages in Ubuntu, keep in mind that AMDGPU-PRO is intended primarily for Workstation customers. Most consumers should be well served by the open source stack which is already included in Ubuntu and other distros, and continues to improve rapidly as we upstream support for new products, performance improvements, and continue to close the gap on features.

By the way, in addition to managing our open source graphics team, I took on packaging of AMDGPU-PRO because I was dissatisfied with the fglrx installer, as a driver developer, as someone who had to support customers struggling with install, and as a user. So it's not different departments, as you suggested. I care deeply about the Linux install experience and, as someone who's been using Linux exclusively since 1993, I like to think I have a pretty good idea of what it should look like but I'm open to suggestions on how to improve it.

[dungeon]

Instead of quoting this i just edited it and somewhow delete it... shit happens Hopefully you had read it already...

For QA and some customers, we require installation of a consistent set produced by a full stack build from a known set of commits. For example, "apt-get install amdgpu-pro=16.60-379184" should install all ~50 packages from build 379184 and only build 379184. This is unusual and I don't know of an easy way to do it.

Just depend on versions for every amdgpu-pro meta, in Control instead of:

Depends: amdgpu-pro-dkms, libgbm1-amdgpu-pro, libgl1-amdgpu-pro-appprofiles...

should be:

Depends: amdgpu-pro-dkms (= 16.60-379184), libgbm1-amdgpu-pro (= 16.60-379184), libgl1-amdgpu-pro-appprofiles (= 16.60-379184)...

Blah, blah... just in case to mention, you don't need to edit that every time of course... in your amdgpu-pro lab control template you can just setup once something like:

Depends: amdgpu-pro-dkms (= ${binary:Version}), libgbm1-amdgpu-pro (= ${binary:Version}), libgl1-amdgpu-pro-appprofiles (= ${binary:Version})...

etc...

[L_A_G]

I have the relationship correct. It is up to AMD to ensure consumer availability they do benefit from it the most (the OEM can still go back to selling Intel products). There were a lot of boards introduced and demoed last year August/September from all the major manufacturers (MSI, Gigabyte, ASUS, ASrock). So far I have only found the low end Asus one. Where are the others ? Don't tell me they poured R&D money into products they do not intend to sell ?

Nope... AMD really doesn't have much power over what kind of products OEMs chose to make and how they sell them. All they can do is try to sell them their parts and hope they decide to take the plunge and make consumer products with them.

You should know that there's quite a lot of engineering, manufacturing, marketing and distribution costs that incur when you go from a working prototype to a product on store shelves. Because of this it's pretty common that a company comes to the conclusion that a product they currently have in prototype form won't make it's money back and as a result just cancel further development and never bring it to market. It's not just products that haven't yet been shown to the public, it's also products that have been shown to the public already.

The only conclusion is that there's not enough chips to sell. Or that everybody is waiting on Zen. Either situation is not beneficial to AMD.

Seeing how there's been no shortage of other chips made on the same production nodes and we're talking about some pretty mature production nodes that have been running for years already it's pretty clear that it's not because AMD can't make the chips.

[wizard69]

Early march, it seems. I was expecting it late february, but it doesn't make a big difference, in the end.
I feel you. I desperately need to move away from my 4GB DDR2 system

Hey my Main Linux box is still 32 bit, need real 64 bit performance with a MODERN GPU!

[wizard69]

Not sure I understand. It only left cards unsupported if you ignored our advice and a dozen or so internet articles and installed a distro version (16.04) that we were not yet supporting with the proprietary/hybrid driver (and which was not listed in the "supported OS" section of the release notes.

The one exception to that AFAIK would be if you were running SI hardware on one of the HWE versions of Ubuntu 14.04, in which case I *think* the Ubuntu updater might have forced you onto a 14.04 LTS HWE version with 16.04 kernel and that *would* have left you unsupported IFF you needed OpenCL and so were not able to move to the all-open stack.

We were trying to get SI support into AMDGPU-PRO before that happened and we made it for most of the WS cards, but not yet all of the consumer cards.

Don't let these guys get to you, we really like the fact that someone from And checks in here from time to time!!!!

[twriter]

Just depend on versions for every amdgpu-pro meta, in Control instead of:

Depends: amdgpu-pro-dkms, libgbm1-amdgpu-pro, libgl1-amdgpu-pro-appprofiles...

should be:

Depends: amdgpu-pro-dkms (= 16.60-379184), libgbm1-amdgpu-pro (= 16.60-379184), libgl1-amdgpu-pro-appprofiles (= 16.60-379184)...

We thought of that. It should solve this problem but will prevent upgrading individual components, e.g. for bug fixes that don't require a full stack rebuild. We want the ability to install a consistent stack, downgrade/upgrade to another consistent stack, and upgrade individual components.

[dungeon]

We thought of that. It should solve this problem but will prevent upgrading individual components, e.g. for bug fixes that don't require a full stack rebuild. We want the ability to install a consistent stack, downgrade/upgrade to another consistent stack, and upgrade individual components.

Well, consistent and individual upgradable oppose each other, isn't it . Those who wants it custom and individual upgradable, won't install it via meta package that is...

Meta is exactly sort of consistency check Maybe these should install it via meta and then uninstall just meta package and go to unconsistency

Only thing there i think you can do is when you wanna bump some individual package, you should also do that together with new meta package which include exact = version dependency bump of that bugfixed package.

So new meta on every bugfix sounds like solved prob.

[RussianNeuroMancer]

Regarding inclusion of packages in Ubuntu, keep in mind that AMDGPU-PRO is intended primarily for Workstation customers.

I'm afraid that on Vega launch AMDGPU-PRO will be only way to get GPU working for regular consumer who not familiar with git and kernel building. It's Ok for workstation GPU driver to support only LTS releases. It's not Ok for only one available driver for particular GPU to not support latest Ubuntu release. So please make AMDGPU-PRO release that will be published on Vega launch compatible with Ubuntu 17.04. I know couple of people who could buy Vega as soon as it will be available at local stores, and they certainly will not be happy with their choice if installation will be difficult.

[GreatEmerald]

As to the next mid-tier cards - since Polaris launched not too long ago, I wouldn't expect a new mid-tier card for a while. If the Vega11 replacing Polaris10 rumor holds true, that would be the earliest (rumored Q2-H2 2017).

Yea, but I'm not talking that early. I was more wondering "will it be out in one year or two".