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

[twriter]

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.

If I understand you correctly, that's basically the approached we've settled on and are testing now -- full stack meta package dependent on exact versions of the components. We're also adding a dependency on an empty base package to allow easy removal of the whole stack. With this, installation of specific stack release becomes:

apt-get install amdgpu-pro=16.60-379184

To upgrade to the latest release (of all components):

apt-get remove amdgpu-pro
apt-get update
apt-get dist-upgrade

To upgrade to a specific release, e.g. 17.10-456789:

apt-get install amdgpu-pro=17.10-456789

To remove it altogether:

apt-get purge amdgpu-pro-base

These are examples, details subject to change.

[dungeon]

That is OK, but i talked of something else there further cos you mentioned you want consistency but also individual (to say it in windows jargon) hotfixes (which i guess might be optional, temporary or whatever )

What i said there in case you wanna change just one package you should bump version of that one, but you should also correct and bump meta too. That way meta always check for consistency, upgrade/downgrade/specific always work and nothing happen unnoticed.

[oooverclocker]

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

It's no big deal at all as long as generic GPU support works during the installation process: Ubuntu Kernel-PPA mainline

Edit: But of course it would be useful when AMD made sure it does work with 17.04 . Because with my RX 480 I got serious bootup issues when the firmware was not installed on Debian so I had to install it with an old Kernel that didn't support it

[torsionbar28]

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.

Not even close. Manufacturers have plenty of influence. They can provide reference designs to encourage things to be done a certain way, they bundle their preferred set of components under a marketing umbrella (e.g. intel vPro), and they can provide all kinds of marketing and financial incentives to drive OEM behavior. There are many options.

[L_A_G]

Not even close. Manufacturers have plenty of influence. They can provide reference designs to encourage things to be done a certain way, they bundle their preferred set of components under a marketing umbrella (e.g. intel vPro), and they can provide all kinds of marketing and financial incentives to drive OEM behavior. There are many options.

AMD, like any other chipmaker, obviously provides manufacturers with reference designs, but do you really think that in the middle of all the financial hardships of the last few years they actually have the money to pay OEMs to make the kind of products that they want? Because it's blindingly obvious that AMD doesn't have the money to pay hardware vendors to make niche products they otherwise wouldn't want to make.

Blaming this on AMD is just purely delusional. AMD is not Intel, they've never been and will probably never be Intel with billions of dollars to bribe hardware vendors to make certain types of products and not make other types of products.

[boltronics]

Thanks for your reply - sorry I somehow missed it earlier.

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.

This reminds me; I think one of the issues was when purging the packages - it removes the /opt directory instead of leaving it behind if there's nothing else in there. Forgot if I already mentioned that, but something to validate if it's still the case.

I guess I just don't see the reason to have a local repository. Surely AMD can host a repository that has every driver version in it for all supported distros and architectures, which would avoid the need for users to even need to download unsigned tarballs and run shell scripts as root in the first place? It's quite possible to host multiple versions of the same package in the same repository, and have the user specify which one to install (if not the latest version).

I'd be happy to make the scripts I use to manage my internal apt repository public if my employer will allow it - although there's not really all that much to it. It's just a bit of Bash, apt-ftparchive and gpg.

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.

Correct - the file permissions were installed wrong. I admit I also didn't really trust it, since packages weren't signed (at least in the older releases) and were causing warnings when updating - even after fixing up the permissions. This might have since been fixed... I can't remember. I haven't been booting into my installation with AMDGPU-Pro lately, as I've been sticking with Mesa wherever I can.

However I would not expect packages to be upgraded by having them removed first. This is not expected behaviour, and could even break the user setup should application builds that depend specifically on one of the packages AMD provides depend on one of those packages - apt won't let the driver package be removed without first removing the non-AMD package depending on it, which AMD certainly shouldn't be touching. If you just upgrade the driver packages as normal without first removing them, you'll avoid the possibility of such issues.

And of course, if I removed the repository but still had the old driver packages installed, I wouldn't be running into as many problems either.

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.

I'd have amdgpu-pro as a minimal package, and then have it depend on the same specific version of every required dependency. Downgrades will always need to be forced or pinned, but that's normal and expected behaviour.

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.

That's true, but unless/until Mesa supports compatibility profiles, AMDGPU-Pro will always be needed for certain games such as Dying Light. To this day I still get warnings when I attempt to test D3D11 games under Wine if I'm missing compatibility profiles (although I believe there is a long-term plan by Wine devs to address this). My understanding is that Mesa is years away from implementing compatibility profiles - if ever.

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.

Thanks. I think it was fglrx that advertised that it could generate debian packages, but using the flags to enable it would always fail? I generally opt for packages (over install wizards) for drivers where I can (since drivers need root access anyway), simply because there is some level of trust that the thing can be cleanly and fully uninstalled (which I know is often not how it works in practise, but in those situations it can clearly be classified as a bug). However I'd probably prefer an install wizard over having my apt-get command produce security warnings on each use.

I'm not convinced there needs to be a local repository to do what you want - particularly since you already have a shell script that can manually install packages. You could list gdebi-core as a requirement and use gdebi if needed, for example (although even needing that might be a stretch IMO). However If there are legitimate reasons for needing to have the repository installed with old packages, the best thing to do would be to document the setup really well to explain why it's deployed that way to avoid confusion by the end user - since it's unlike any installer I've ever encountered which I can recall (I've been a GNU/Linux user since '98). But by far, my preference would be for the AMDGPU-Pro packages to confirm to standard Debian package behaviour.

Those are my thoughts. I really appreciate your response and listening to feedback, even if you ultimately decide to disagree.

[oooverclocker]

but unless/until Mesa supports compatibility profiles, AMDGPU-Pro will always be needed for certain games such as Dying Light.

In my opinion it's necessary that Warner Bros. overhaul their engine to get rid of the deprecated functions if that's really the case.

[boltronics]

In my opinion it's necessary that Warner Bros. overhaul their engine to get rid of the deprecated functions if that's really the case.

I also heard that Doom on OpenGL required compatibility profiles. It's unreasonable to expect everyone is going to update their (usually proprietary) software that works fine on every other driver stack.

[bridgman]

I also heard that Doom on OpenGL required compatibility profiles. It's unreasonable to expect everyone is going to update their (usually proprietary) software that works fine on every other driver stack.

Not to nitpick, but I think you mean "works fine on two driver stacks (NVidia and AMD proprietary) and doesn't work on any of the others" ?

[agd5f]

I also heard that Doom on OpenGL required compatibility profiles. It's unreasonable to expect everyone is going to update their (usually proprietary) software that works fine on every other driver stack.

FWIW, MacOS does not support compatibility profiles either.