AMD Hiring Ten More People For Their Open-Source/Linux Driver Team

[Space Heater]

I'm not intending to be negative, but should we really expect these new hires to be working on things relevant to the desktop? From the job listing, it seems that their role is primarily to support the enterprise/data-center business of AMD, which is great, I'm just not certain that this will translate to better desktop support or more attention to long-standing bug reports (that are not relevant to the datacenter).

[valici]

Lots of work is being done for future architectures - but for dGPUs we don't push the code upstream until close to launch due to competitive concerns. This is particularly for new architectural generations, whereas for same-generation parts we were able to start publishing code ~9 months before launch IIRC.

Good to know that Navi can drop at any time but it was nice to get some bits before the launch. Thanks

[darkbasic]

but it's not like there is a line where we say "those are too old" other than maybe the pre-GCN cards, or cases where the older chips simply do not have the hardware features required for some newer SW features.

What about DAL for GCN 1.0?
What about hardware decoding for AMDGPU GCN 1.0?
The code has already been developed by the community, but AMD is holding it back not releasing an updated firmware.

[chithanh]

I agree with those who say that Intel support for older graphics is a mess. And that is not even counting the Atoms with PowerVR/Mali graphics that stopped receiving new drivers long ago.

At work, I used to deal with a notebook with Ironlake graphics. That was quite horrible for most of its lifetime, although it somewhat improved near the end. But lots of stuff still broken and/or working worse than on Windows, video playback for example (fdo bug #47858).

About AMD, their Linux drivers are still not quite at feature parity with Windows. No VP9 hybrid decode for example.

[Guest]

bridgman , Brisse - Looks like I got it wrong, somehow I thought my 390 had H.265 hardware, but it doesn't.

As far as RocM and PAL are concerned, they don't officially support Arch Linux. They require the use of external kernels maintained by AMD - which means I cannot just use the normal Linux kernel package in the core repo. And it looks like it includes a bunch of closed source software for OpenCL support (correct me if I'm wrong). Regardless, if I was ok with running non-mainline kernels and alternate driver stacks that required the kernel version to stay static most of the time, then NVIDIA would have been a valid option.

But I am not interested in such a situation - I want driver code to be in the mainline kernel, so that I can take any new version and have it just work. Instead of fiddling with driver code written for old kernels, that's already out of date.

Sometimes, people do need to use newer kernels, due to bug fixes or new features for other hardware - in such a case I don't want to be hampered by some external driver module that breaks as soon as I use a new kernel.

The support is still very clunky and inconvenient for even power users. The stability and reliability problems are very real.

Also, I'm not comparing old AMD hardware support to new Intel hardware support. 4 of those Intel GPU desktops and laptops were used during the same period I was using that one AMD laptop. They all worked beautifully. I'm comparing only hardware released in the same time period.

The 3 new desktops/laptops all have Skylake CPU/GPU and Skylake was first released in 2015 the same year as the R9 390. So yes it is an apples to apples comparison. In fact that one desktop with the Skylake CPU/GPU is where I use the R9 390. Same motherboard, RAM, PSU, storage and exact same software stack. Intel driver works great while AMD driver is always buggy.

[Guest]

chithanh - Discussion of PowerVR/Mali is invalid, since those are obviously not Intel GPUs. Sure they were branded as Intel GPUs , but they're clearly not actual Intel GPUs.

[muncrief]

I have that Athlon 5350 APU and could understand you there, that works the best with FGLRX or AMDGPU drivers, but not with default Radeon driver

For awhile nothing worked. No matter what I tried after a day or so my system would completely lock up and the only way to recover was to do a hard reset. I have no idea how the drivers work now because I lost a few movies due to disk corruption caused by the hard-lock GPU crashes, and I'm certainly not going to risk my disks again to test something for AMD that should have never needed testing to that degree in the first place.

And I guess that's the most infuriating part of this whole thing.

AMD simply won't acknowledge the rotten things they've done to their Linux customers, and at the very least apologize. They just keep saying things like "Sheesh, well everyone knew you shouldn't have bought AMD GPUs then" or "What the heck is wrong with you?, everyone knew not to buy that specific model" and on and on and on.

Just a little truth from AMD would be nice.

AMD needs to admit that they thought Windows 10 was going to take over the world and so made a conscious decision to completely, and unethically, abandon their Linux customers. And they did it in a very deceitful way, pretending they were "open source" heroes who only wanted to advance such a wonderful cause. When in truth they simply abandoned Linux and only left a handful of developers to "contribute" to driver development. Leaving uncounted loyal, AMD only, customers to wallow in the dirt.

So as you can tell, after three years AMD's excuses mean nothing to me. I'm furious and will never buy an AMD CPU or GPU again.

The AMD corporation is rotten to the core. And every day we still live without reliable working drivers proves it.

[bridgman]

What about DAL for GCN 1.0?

AFAIK the pre-DAL code already supports all the functionality that the HW includes. Most of the requests for DAL/DC on SI seem to be based on the assumption that it would give them functionality that we added for the first time in CI HW. Other than as a make-work project for the display team it doesn't seem to have a lot of benefit.

What about hardware decoding for AMDGPU GCN 1.0? The code has already been developed by the community, but AMD is holding it back not releasing an updated firmware.

It's not a question of "not releasing an updated firmware", it's about not being able to implement firmware with the functionality required for amdgpu *and* the functionality required to work in an open-source-safe driver.

Saying "not releasing" implies that we have it and are just being ****'s about releasing it, which is not the case.

We eventually worked out how to implement open source support for SI in the radeon driver (I think Christian figured it out) but AFAIK there is not enough room left in the microcode store to do it with newer (amdgpu-compatible) firmware. IIRC the last comment from agd5f on this was that porting the radeon code across could work.

[R41N3R]

Unfortunately I have to agree about AMD. I simply can't afford to buy another AMD GPU, no matter how cheap or "competitive" it is. I spent a pretty penny on one of their "latest and greatest" GPUs, a Sapphire Nitro R9 390, about 3 years ago and it's only been intermittently functional for about 6 months at most. Unfortunately I bought it about the same time AMD dropped Linux like a hot rock, and pretended it was a "wonderful" thing for "open source" development. And now that AMD has been completely negligent for three years they're beginning to call my card "too old" to support. How convenient for them.

In fact at this moment I'm desperately patching kernels trying to build a functional one that will support amdgpu and have working suspend/resume. I finally patched a 5.1 development kernel the other day and got suspend/resume to work, but later found it froze Thunar when copying files across the network. So I'm back at it again today.

As for Nvidia, I really don't see any other realistic choice, and at this point it's ridiculous to care about open/closed source. If I'm going to spend $300 or $400 or more on a GPU I need it to work. In fact for awhile AMD drivers didn't work at all on my home theater Athlon 5370 integrated GPU so I had to go buy a discrete GPU, and it was literally impossible to choose AMD. So I bought an Nvidia GT710 and it has had zero problems in over a year.

In fact it really doesn't matter if you get an old or new AMD GPU. There is simply no way to know if it will work today, tomorrow, or the day after tomorrow. AMD has zero interest in its Linux customers, and is doing the absolute minimum possible for us. So I have no alternative other than to buy Nvidia from now on.

I think I had the same issue with the Athlon 5370 after a new kernel upgrade, but it was just another kernel parameter and then it worked again. Not nice, but easy to fix and at that point we could switch already between radeon and amdgpu.

[Brisse]

As far as RocM and PAL are concerned, they don't officially support Arch Linux. They require the use of external kernels maintained by AMD - which means I cannot just use the normal Linux kernel package in the core repo. And it looks like it includes a bunch of closed source software for OpenCL support (correct me if I'm wrong). Regardless, if I was ok with running non-mainline kernels and alternate driver stacks that required the kernel version to stay static most of the time, then NVIDIA would have been a valid option.

But I am not interested in such a situation - I want driver code to be in the mainline kernel, so that I can take any new version and have it just work. Instead of fiddling with driver code written for old kernels, that's already out of date.

Sometimes, people do need to use newer kernels, due to bug fixes or new features for other hardware - in such a case I don't want to be hampered by some external driver module that breaks as soon as I use a new kernel.

The support is still very clunky and inconvenient for even power users. The stability and reliability problems are very real.

As far as I know, pretty much no vendor officially supports Arch in any way, shape or form, but since ROCm is open source it can easily be deployed on Arch either by the community, or the individual user. The kernel bits have been mainlined since 4.17 for Fiji/Polaris and 4.18 for Vega, and if I'm not mistaken, Arch is currently shipping 4.20 so there's no need for special kernel or kernel modules any more.

I've been successfully running ROCm on Debian Sid. At first I had to rely on either custom built kernels or DKMS but since kernel 4.17 it's been running fine on the kernel provided by Debian repositories. Note that Debian, just like Arch, is not officially supported, but thanks to the open source nature of ROCm it can be deployed anyway. I belive Fedora is working on getting it into their officiall repos and I'm sure more will follow, including Arch. At that point it should be as simple as 'sudo pacman -Syu rocm' and you will be up and running