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

[TheYoshiGuy]

Cool, maybe 1 of them will be willing to debug some of those system-breaking bugs plaguing the opensource driver stack when trying to run console emulators like Dolphin, Yuzu, Cemu and the minor graphics glitches in rpcs3.

[bridgman]

AMDGPU driver is still experimental for the R9 390, while on Windows Vulkan 1.1, Open CL 2.0 and H.264, H.265 decoding and encoding are officially supported and it's not considered an experimental driver for the 390.

Sorry, I just noticed this. The packaged Linux drivers support essentially the same functionality on Linux, although I'm not sure about H.265 encoding.

It's only upstream that we use the "experimental" flag. The same code runs by default in the packaged drivers.

[muncrief]

Okay, I've been patching and compiling kernels all day and seem to have one that almost works with everything on my R9 390, though I've only had about a half hour to test it. Note that the desktop background is still lost on resume, but that's a problem going all the way back to around 4.18.15.

However resume does seem to work correctly, and my monitor says FreeSync is active though I have no way of reliably testing it to see if it's operating correctly. Vulkaninfo returns reasonable values, though clinfo still returns nothing. Quick tests with both native and wine Steam games seemed to work as well.

So, for today at least, the magic combination is "linux-amd-staging-drm-next-git" plus the patches at "https://lists.freedesktop.org/archives/amd-gfx/2019-February/031437.html".

Note that there are 35 patches but today's "linux-amd-staging-drm-next-git" already has most of them. But unfortunately I didn't keep track of the few patches that were applied because I'm just plain tuckered out after six weeks of debugging, bisecting, and compiling. However the kernel doesn't work without them, so you'll just have to try and apply all of them and skip the ones that aren't needed.

Note that I couldn't find any other current kernel versions that work with the patches. There were two others where resume was fixed by the patches, but they froze on large network file transfers.

In any case I assume most people on this forum are engineers and know how to patch and compile the kernel, but if you're running Arch or a derivative and don't know how I can give you fairly complete instructions on the build. Just request it and I'll post the instructions here.

[wizard69]

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.

No what you are being is a complete jerk, fouling a thread that is frankly great news for AMD users.

As for your OLD hardware stop with the childish behavior! I have a whole cellar full of old hardware, it is a fact of life inthetech world. Beyond that if you have every lived through a company suffering from the lack of profits and poor management 3 years is nothing to engineer and achieve a recovery. AMD did what it had to do to stay afloat. If you can’t understand that you really have zero life experiences and shouldn’t even be commenting any where!

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.

Be happy with an automatic reply. AMD could have easily collapsed and thus no response at all.

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

If you step back just one minute you will see that you flooded this thread with crap that has nothing to do with the very positive news that the article presented.

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

Actually post like yours leads to companies saying screw it that persons problems are not worth addressing because, one; the individual is to ignorant to understand what AMD has gone through. Two; even if all the fixes magically appeared there would still be complaints coming from said individual.

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.

Actually they need to ignore what has become known in industry as “the toxic customer”. I just find it to be very impolite to have a thread that has nothing to do with your mental health problems, be polluted by your nonsense.

[wizard69]

To Brigman and the other AMD employees that frequent this forum, I just want to say thanks for all the efforts you guys have put in place over the years. It is pretty apparent that a few posters here have no idea what it is like to go through a reorganization, austerity budgets and terrible management decisions, sometimes not knowing if you will have a job come Friday. I’ve personally have gone through such and frankly ended up working with a bunch of Kodak employees when the bottom fell out there.

In any event i believe most of most of us are thankful that AMD has survived and continues to support Linux. I’m also thankful for the on going communications from AMD, even if many seeming couldn’t understand what was in writing about the direction AMD was taking with GPU drivers. That doesn’t mean things are perfect but any rational person can see that things have been getting better with every kernel release.

So so keep up the good work and don’t let the tools get you down.

[Brisse]

and my monitor says FreeSync is active though I have no way of reliably testing it to see if it's operating correctly.

No, it's not working for you, and there is no way that monitors can reliably tell if it's working or not, so you should really just ignore whatever it tells you. Open source Freesync requires at least Linux 4.20 and Mesa 19.0.

[muncrief]

No, it's not working for you, and there is no way that monitors can reliably tell if it's working or not, so you should really just ignore whatever it tells you. Open source Freesync requires at least Linux 4.20 and Mesa 19.0.

Thank you for the information. The kernel is a development version of 5.1, so I'll chroot and compile Mesa 19 and see if I can find some way of testing FreeSync. Do you happen to know of any way to do it, or should I just run games and observe the refresh rate and look for glitches?

[Brisse]

I’m also thankful for the on going communications from AMD, even if many seeming couldn’t understand what was in writing about the direction AMD was taking with GPU drivers.

Honestly, I think it's a huge privilege for us that we have several AMD employees openly involved in the discussions on this message board. I don't see many from the competition doing the same thing, and I can only imagine they could risk their job if they accidentally said the wrong thing or overstepped their boundaries. We should be greatful for their participation, and also a bit careful for how much pressure we put on them so we don't get them into trouble and loose the privilege we currently have.

[theriddick]

I look forward to moving back to a AMD card once they release a 1080TI killer that can fit in a ITX system. The Vega VII could but they aren't allow AIB cards for that thing, it has allot of empty space on the PCB. (plus its not a 1080TI killer)

[Brisse]

Thank you for the information. The kernel is a development version of 5.1, so I'll chroot and compile Mesa 19 and see if I can find some way of testing FreeSync. Do you happen to know of any way to do it, or should I just run games and observe the refresh rate and look for glitches?

With my own monitor, an Asus MG279Q, it's easy to observe, becouse the refresh rate in the OSD dynamically changes according to the framerate whenever Freesync is working, but a lot of monitors lack that feature, which means it can be difficult for a non Freesync trained eye to observe if it's working or not. Maybe AMD's Windmill demo is working in Wine? It's a simple graphical application for Windows which makes it pretty easy to spot tearing or stuttering and thus if Freesync is working or not.