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

[bridgman]

True, irony there is that maintaining FGLRX for let say 2 years more with just X and kernel updates would cost them nearly nothing

It actually did turn out to be quite expensive; much more so than I would have expected. Part of it was the size of the code base, but this was also a time when a number of kernel functions were being deprecated and replaced with new GPL-only functions, so the driver impact was much larger.

[bridgman]

Still missing the documentation about open source auto-rotation driver for mobile Raven Ridge. Hopefully one of developers will work on it.

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

[dungeon]

AMD simply won't acknowledge the rotten things they've done to their Linux customers, and at the very least apologize.

I think companies usually apologize by making things worse

Intel didn't apologized for Meltdown, they actually used Spectre argument to dimminsh an issue. And on top of that we got even CoC, which even AMD likes... irony can't be bigger really

[dungeon]

It actually did turn out to be quite expensive; much more so than I would have expected. Part of it was the size of the code base, but this was also a time when a number of kernel functions were being deprecated and replaced with new GPL-only functions, so the driver impact was much larger.

He, he, i know that But how do you know that it is expensive when you didn't do it, it costs you nothing anyway

[Brisse]

So basically this started as an information about AMD hiring people for their free-as-in-freedom driver team, but ended quite much as a near-flaming discussion about AMD, intel and nvidia drivers in comparison and support for non-recent hardware. Ah, well, business as usual I guess.

Gosh, I wish I had the skills to apply, but I guess like most people around here, I don't have what it takes. I can only hope they find the right people for the job

[bridgman]

What the heck?

After spending $350 on a GPU that AMD immediately left to languish for years, directly addressing their employees and expressing disgust and dissatisfaction is not productive or polite?

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.

[seijikun]

Hello bridgman, great to hear from you as always. Are you sure about this for encode? My understanding (which is little) is that the new cards need the "Advanced Media Framework", which is a windows only thing. I haven't been able to use hardware accelerated encoding under linux with my RX 480, but decoding works fine. Other than that, and ROCm (which won't work because I have PCIe2), everything works great with the amdgpu driver.

Keep up the great job.

Also, it would be cool if AMD supported Arch officially. It's a bleeding-edge community, just saying

Hardware-Encoding (h264 and HEVC) work just fine on AMD cards using VA-API using GStreamer. Example for live-encoding a desktop recording:

gst-launch-1.0 -ev ximagesrc use-damage=0 endx=1919 endy=1079 ! video/x-raw,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12 ! vaapih264enc quality-level=3 rate-control=2 ! "video/x-h264,profile=baseline,stream-format=byte-stream,framerate=60/1" ! h264parse ! mp4mux ! filesink location=test.mp4

I don't have the exact HEVC pipeline right now, but that worked as well on a R7 2400U for me.
However, some features aren't enabled / implemented / ...?
An example for this would be the missing support for B-Frames: (https://community.amd.com/thread/224074) in the cards firmware.
Using AMF and Windows, the same cards support B-Frames.
bridgman Is there a specific reason for why features like this aren't in the distributed card-firmware for linux?

[bridgman]

He, he, i know that But how do you know that it is expensive when you didn't do it, it costs you nothing anyway

We had several years of history doing that maintenance, although it varies from year to year depending on the degree of kernel and X changes.

[dungeon]

We had several years of history doing that maintenance, although it varies from year to year depending on the degree of kernel and X changes.

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 Where it shouldn't happen, you do it

As things can't be without it iriony is that where sharp U-turn is expected to happen it does not actually happen Like with GCN 1.0 and 1.1 should use AMDGPU long ago if you ask me, but nope you think that is fine for your userbase

May i ask, are you crazy or something to keep having two drivers so much time for the same hardware in the kernel? You should do that off of mainline kernel if you need it that much

[bridgman]

bridgman Is there a specific reason for why features like this aren't in the distributed card-firmware for linux?

That conclusion doesn't look right, and I don't think it directly follows what Christian said either. It seems unlikely that the firmware for Windows would include B-frame support while the firmware for Linux would not... and more likely that the Windows driver team found a way to work around it. Don't know for sure though.