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

[muncrief]

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.

Thanks for the further info. It takes quite awhile to compile llvm so I probably won't be done tonight. But I'll try to come back in the next day or so and report the results.

[andrei_me]

TL;DR of the thread:

We started praising AMD for the open-source support, then sour owners of 390 took the thread to complain about it's driver situation.

Which to me seems specific to this and some cards of the same period, and some lower end APU seems to have the same driver situation

But anything above polaris seems to be in a great situation

[nuetzel]

Right. We were the primary contributor to Mesa/CLover for a while but after a couple of years with little or no community uptake we went back to our own code base instead, which already had a full OpenCL implementation. We also open sourced the ROCm version of our OpenCL code base.

But sadly ROCm isn't running without PCIe atomics (PCIe 2x) on Polaris... --- Will we ever see the 'new' firmware? ;-)

[bridgman]

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.

Thanks for the info. I'll go look at the patches as well.

Are the problems you are dealing with at this point mostly related to suspend/resume, or are you still seeing stability issues ?

[TheYoshiGuy]

TL;DR of the thread:

We started praising AMD for the open-source support, then sour owners of 390 took the thread to complain about it's driver situation.

Which to me seems specific to this and some cards of the same period, and some lower end APU seems to have the same driver situation

But anything above polaris seems to be in a great situation

Unless you want to run any modern console emulators, in which case, Vega cards are the worst you can buy, with Polaris a close second.

[muncrief]

Thanks for the info. I'll go look at the patches as well.

Are the problems you are dealing with at this point mostly related to suspend/resume, or are you still seeing stability issues ?

My main problem was resume starting with kernel 4.19.7 (4.19.0 - .6 wouldn't boot at all). The computer was actually resuming and I could SSH into it, but the monitor was black and displayed a "Signal not recognized" error. That seems fixed now. However another resume problem, starting around 4.18.15, remains. Resuming always resets the desktop wallpaper to default, and sometimes opens the "Display Properties" dialog and resets the monitor frequency to default. And a few times it's opened the Trash for some reason. However I haven't seen the dialog or Trash open yet this evening, and I tried resuming a good 20 times or so. So the only remaining problem may be the wallpaper reset issue.

I spent a week or so bisecting it back when it first started happening but could never isolate the problem. For some reason these resume issues seem to be tightly bound to some other code that, when omitted, causes the display not to come on at all. So with all the resume issues bisecting either resulted in the display not working at all, or working with the error. I could never get down to that last precious commit that caused it to work/not work. However there were usually compilation problems as well, so I had to disable various modules or I couldn't get a build at all. It was really a mess!

By the way, the only error message I could ever find is "[drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4!" But it seems a lot of people have this message so I'm not sure if it means anything.

I haven't had a lot of stability issues with my R9 390, those were mostly on my home theater's Athlon 5370, and it was a long time ago. I ended up getting a GT 710 and really don't want to mess with the theater because man, I'm old and really don't like all the mean reality shows, and good god everything is like a bad soap opera with different characters and backgrounds now! It doesn't matter if they call it science fiction, drama, comedy, romance, whatever, I swear everything is being generated by the same script software So my theater is full of mostly old comedy and science fiction and over a thousand old TV shows. From Gilligan's Island, to I Dream of Jeannie, the Monkeys, Addams Family, Munsters, Hogan's Hereos, F-Troop, and on and on, I have a plethora of anxiety relieving content, and I can't risk messing it up!

But I digress

I'll keep testing things over the next few days, and I'm compiling Mesa 19 and LLVM 8 so I can see how everything integrates. I'll pop back in and report whenever there are errors or progress.

Thank you for listening and looking into these issues. I hope you can tell I really don't want to abandon AMD, but it's been a long and difficult three years. Sooner or later one has to make a decision on whether to continue doing the same thing or change, and I don't think I'm alone in being at that point. But I'm still rooting for AMD, if for no other reason than Jerry Sanders and that freakin' amazing Athlon 64! After all these decades I still can't get over it

[ossuser]

@bridgman

Nice to see more devs on opensource.

I was wondering though: recently I heard that AMD will implement the chipset stuff for the coming X570 boards itself ?

This would provide AMD with the chance to opensource and open up a lot of the chipset.

Is this being considered by AMD ?

[vein]

Firstly, A big thanks to AMD for their Opensource efforts. I have been running 2 fury cards that have been perfectly stable with no problem at all during the whole time I have owned them (3 years now). I am running on Arch and I move forward very fast and you still manage to keep drivers very stable, a lot more stable than for example Intel whos skylake drivers have given me a lot of headache during the same period of time. I also have a laptop with vega that is running perfectly stable so yes, I am very very thankful. I will buy only AMD gpus in the future.

Secondly, why is it, that every time there is an article about AMD doing good stuff for the open source community, there is also a few people (never the same people) who need to come forward and complain that AMD is crappy, does not care and the competitors are so much better. Clearly, there are cases of bad drivers that maybe apply to your card but guess what, the same goes for the competitors. For me, Intel and Nvidia cards have been pure hell while AMD just works.

Also, it is almost funny to read the comments here, because for anyone that actually uses the oss drivers from AMD it is very easy to see that most of these comments are simply FUD and lies.

[vein]

Also, about the article itself... This would be a dream job for me...too bad AMD has no swedish office...

[Nille_kungen]

This makes me think that the next-gen GPU might differ more from then current GCN since that would need more driver changes.

Also, about the article itself... This would be a dream job for me...too bad AMD has no swedish office...

I think you might be able to work from home, apply for the job to find out.