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

[finalzone]

This isn't ringing any bells... is it something we talked about previously

Alas not as I was unable to find any reply about that missing auto-rotation screen driver for mobile Raven Ridge.

The related issue was reported not only on Fedora kernel team as one of Red Hat developers vainly attempted to contact you but also Linux kernel and AMD own community forum below:

Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1651886

Linux kernel bugzilla

https://bugzilla.kernel.org/show_bug.cgi?id=199715

AMD community forum

https://community.amd.com/thread/235302

The information about the AMD Fusion Sensor HUB is needed to understand its functionality to create at least a generic driver. I, as one of reporter of the problem, was very surprised by the difficulty and the frustration to find that details about that component for months. Should an answer be provided, I am sorry for the noise.

[bridgman]

Well, you should do maintaince for 2 years in parallel with amdgpu pushover to dimminish compliants too much and that is it
Instead your devs prefer U-turns more it seems

... which in turn would have delayed amdgpu development and increased complaints in a different area. It's tough to say which approach would have been best.

Obviously we asked for enough headcount to be able to do both in parallel, but as you probably remember we were still losing money every year at the time and there wasn't any money for new hires, so we struck the best balance we could with the people we had. IIRC we did some bug fixing on fglrx but were not able to keep kernel & X updates going on it as well as bringing the developers up to speed on the open source code base and writing amdgpu.

Most of the fglrx customers were on relatively slow moving distros and were able to keep using their systems during the transition without kernel/X upgrades, but people using fglrx for gaming on faster-moving distros had a harder time. That said, the options were really to go ahead with the amdgpu transition or to stay with fglrx and radeon (with most of the developers working on fglrx) for another several years.

[muncrief]

I think ms178's point was that if you were addressing the people who made the staffing decisions for Linux vs Windows years ago that would be reasonable, but beating up on the individual Linux developers doesn't accomplish much except to the extent it results in us adjusting priorities WITHIN the Linux team... and that has limits because the skill sets for various parts of the GPU are so different.

We started building up a small power management group within the Linux team about 18 months ago - before that the "power management team" was pretty much Windows only plus what a couple of developers could figure out in their free time. We do still have quite a lot of catching up to do relative to Windows though, and we do need to keep supporting new GPUs as they are developed.

Well, I'm not beating up on anyone. In fact I'm being as civil as possible while finally being as direct as possible. Three years is my waiting limit for GPU drivers.

And I've sent multiple emails to AMD, though the last was over a year ago.

All I ever received back were automatic "Thank you for contacting us" replies.

So AMD may not like hearing the truth, but I'm here to tell it.

Like I said, their way forward to redemption is simple - acknowledge their errors, apologize for them, and fix them.

Not in a month or two months or three months, or another year or two years or three years.

They need to fix them now.

[angrypie]

Ayy

^{(sorry not sorry)}

[dungeon]

... which in turn would have delayed amdgpu development and increased complaints in a different area.

Nope, it won't if you are capable to make things clear Instead you prefer to play dirty dance, instead of learning to say No

Your changelogs for blobie were always shitty, everybody remember, knows that and laughed

It's tough to say which approach would have been best.

The best is normal, normal is not tough at all if you are normal or at least if you strive to be normal. Instead, if you are not or prefer not to be that is an huge issue

[coder]

Those interested in potentially working for AMD out of their Markham (Ontario, Canada) office

Ah, so this perhaps explains why AMD's GPUs have recently featured worse perf/Watt than those from California-based Nvidia.

Perhaps if they designed their GPUs in somewhere like Texas, with much higher air conditioning use and much less heating, it would give the engineers more incentive towards power-efficiency.

[dwagner]

We started building up a small power management group within the Linux team about 18 months ago - before that the "power management team" was pretty much Windows only plus what a couple of developers could figure out in their free time. We do still have quite a lot of catching up to do relative to Windows though, and we do need to keep supporting new GPUs as they are developed.

If power management alone requires a whole team for programming the operating-system specific part of it, then something about the design of the GPU seems very wrong. Why would power management not be entirely controlled by the (anyway huge) firmware, with only some tiny interface for the operating system to choose profiles or get information on the current and available states?

Also, if new GPU hardware can be designed and produced quicker than the drivers can be adapted to them, that also raises questions whether adequate modularization was part of the hard- and software design.

I totally understand when driving new fancy features or intense optimization takes a lot of effort, but it is the most basic features where the amdgpu driver is currently lacking: Being able to reliably deliver an image to connected displays (even after disconnecting/reconnecting/sleeping) and not crashing the system.

I appreciate that AMD says they want to hire additional developers, and if I was currently looking for a new job, maybe I would apply, if only to find out whether usable internal documentation exists on the hardware and firmware, because from what I see in the git commits, it seems like the developers currently need to find out how those two work in a process of error-and-retry, rather than by reading dependable internal documentation. (And if that suspicion is correct, it will be hard to hire and retain serious developers.)

(When I was programming X11 drivers for NCR graphics chips in the 1990s, there was excellent documentation available on the hardware, even to non-NCR-employees under NDA, with only very minor surprises coming up during driver development. Sure the chips were far less complex back then, but the more complex they are, the better the documentation should be.)

For almost 2 years now, I share the frustration of those who bought some AMD GPU and never experienced a sizeable time period where the driver was not crashing the system again and again.

[wizard69]

Yeah, and the best way to compete with Intel and NVIDIA, is to support all features on existing GPUs. Given their poor track record, when compared to Intel I'm not feeling so good about spending money on another high end AMD card. If they weren't willing to properly support $300 card like my R9 390, I'm not optimistic about spending money on AMD cards if there's competition with way better open source driver support.

Of course, I'm definitely not going to buy NVIDIA due to their signed firmware, closed source driver and stupid EglStreams Wayland stunts. But if Intel releases a dedicated GPU,I'd rather take a chance with that even if it is unproven. The past isn't always indicative of the future, but it does factor into most decisions.

The majority of the problems in the past are directly related to simply not having the cash to support a large number of software engineers. Yes some of that cash flow problems are management related but look at it this way they stuck with open source through out of n of the companies toughest periods ever. That right there makes the company worth supporting. They could have easily said Linux wasn’t worth the manpower allocation. Instead we see them coming out of this dark period allocating even more resources to Linux.

As an aside my my biggest problem right now with my Mobile Ryzen platform is HP and the hoops one seemingly has to jump through to do a BIOS update. AMD isn’t always the nexus of frustration for users.

[angrypie]

Why would power management not be entirely controlled by the (anyway huge) firmware, with only some tiny interface for the operating system to choose profiles or get information on the current and available states?

Probably because desktop workloads are not at all predictable and no firmware magic will cater to all use cases. Software knows better what kind of performance it wants from your hardware.

[wizard69]

Neither API is important for desktop users, companies running servers, or workstation users. And yet they support it.

This right here indicares to me that you have a very distorted view of the situation because these things are very important to desktop users. Especially anybody with a technical bent.

The problem here here is that you are whining about AMD taking steps to correct the problems everybody knows that they have. Frankly I do not understand what your problem is. AMD finally has the revenue to hire engineers and you shit all over their efforts to do so!