AMD Is Hiring Another Mesa/RadeonSI Driver Developer

[Enverex]

May be worth pointing out that it's Markham, Ontario rather than Markham in Wales (which is the more well known of the two).

[dungeon]

I take this as a sign things are going well at AMD. Being able to hire is a big change from the days of layoffs and such.

Windows gained share, Playstation still selling well, Ryzen was Epyc or so Only memory is expensive, everything else is fine if it does not crash then go to bugzilla

Stan Lee passed away, so I think i will play Spider-Man exclusive again now on PS4... Maybe POWER22 will emulate this easely at a Year of Linux Desktop, who knows

[xiando]

I take this as a sign things are going well at AMD. Being able to hire is a big change from the days of layoffs and such.

They missed expectations last quarter. I do have a feeling Q4 will be very good on the CPU price with AMD CPUs accounting for 75% of all retail CPU sales in Europe right now. Intel is focusing it's limited production capabilities on enterprise chips so we have i3's competing against r7's which is just stupid. Last housefire i9 consumer CPU from Intel competes at a price-point where you can buy a Threadripper.

Don't think the GPU side will be reporting strong numbers, though. Used market is overflowing with cheap cards from miners bankruptcy estates.

[duby229]

Ok, well here's the thing - I've never had such problems with the Intel GPU driver. They do major rewrites as well, add new features as well. I've never experienced the same level of brokenness on an Intel GPU driver.

And it's not just one incident - it happens again and again and again. The main reason I used AMD GPU driver instead of Radeon driver, is because the AND GPU driver was more stable and worked better than the Radeon driver!

Considering how convoluted their hardware is and also the shear amount of errata differences between generations, Yeah, Intel's OSS drivers are fairly stable. Their drivers -do- still hang the GPU, but I've never had an Intel GPU not recover, so it hasn't been painful.

[schmidtbag]

They should focus more on their kernel driver, it just keeps breaking all the time, atleast for my R9 390. Now it's so broken it's interfering with suspend and causing null pointer dereferences in the kernel. I just gave up and started using Intel GPU - once Intel launches a dedicated GPU with the same driver support and quality they have now, I'll just throw away the AMD card.

I have a R9 290 (basically the same thing) with amdgpu+radeonsi+radv and I don't encounter any problems with that at all. Using the DC/DAL drivers causes problems, but I have no use for that anyway.

[xiando]

I guess per CoC nowdays developers are expected to be "harassment free, mild and humble" instead of StronK

AMD is looking for someone to co-ordinate with distributions and related free software projects whichi does require some people-person skills. Unlikely it's related the CoC, it's more about being able to get along with MESA developers, distro people and so on. It's a hard job. Not sure I could do it since I don't like people and specially not some.

[illwieckz]

So Guest wrote this words:

They should focus more on their kernel driver, it just keeps breaking all the time, atleast for my R9 390.

And a lot of people answered out of topic. Because I also have an R9 390 and I know his pain, I'm very tempted to answer for him to the faulty replies. Let's go…

Whining does not help, make good bug reports. For me, AMD had fixed fatal bugs in two weeks.

This is the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=91880

This bug report is 3 years and 2 months old, has two duplicates, received 211 comments written by 38 individuals, has 24 attachments attached to it (more in duplicates), and is a 23 000 word thread. There were screenshots, bios dumps, Xorg and dmesg logs, etc. Some workaround were suggested (some being kernel patches).

Please stop assuming and telling others they are uneducated people for the sole reason you haven't faced yourself their issue.

I have used AMD graphics 4 years now. The Linux kernel is worlds largest project, you need to understand its complexity.

I'm using AMD graphics since 10 years and 11 months, it's easy to know: look at the date I joined Phoronix, it's written on the left of my post. I joined Phoronix after having bought the HD 2600 PRO AGP (see my 1st post on a related topic, this was already a big win by AMD since the open source driver started to support the GPU before the closed one at this time).

Please stop assuming and telling others they are uneducated people for the sole reason you haven't faced yourself their issue, yet again.

For RX560 and RX570 kernel 4.19.0 from kernel.org is the best at the moment. Use a rolling release OS and Mesa git, so that your whole system is up to date.

He is not asking for RX560 support, that's out of topic. Stop making assumptions about what people does. I ran ppa kernels then liquorix kernels and oibaf then padoka's mesa unstable ppa for years (I just stopped to use liquorix kernels because of file-system instabilities and upstream kernels are now on on-par for this gpu support, not saying it's complete, saying it's on-par). Stop making uselesses advices that are known to not fix the issues. Stop using any other GPU than R9 390 to say something about linux support with the R9 390 GPU.

if the newest kernel breaks for you, just fallback to your previous working kernel.

There is no “previous working kernel” for this GPU yet. We are still waiting for out-of-the box support. Yes it's a shame for a 3 years old GPU but that's true.

Because yes this GPU is already 3 years old, “The Radeon 300 series cards including the R9 390X were released on June 18, 2015” Wikipedia says.

I feel like way too many people here get locked into their distro's kernel. Compile your own!

Unfortunately this is out of topic. I know how to compile my own kernel, I even wrote patches to hardcode a workaround.

4.19 will be an LTS kernel, so we might as well start submitting bug reports and getting these things fixed up for ourselves and others.

Reports are already there, AMD knows them, AMD people like Alex agd5f Deucher, John bridgman Bridgman and Marek marek Olšák were involved in the bug thread I linked above. AMD knows. I'm not saying that's their fault. They are busy bees and do an impressive job, but yes AMD has to hire someone more to handle this kind of issue, doing the “ensuring it will be fixed one day” role.

Progressions will always have also its regressions, that is nature of development.

This is not regression, regression means this worked at least once in the past. We are still waiting for this day to come. This is not ready yet.

Suspend is a sad story on amdgpu unfortunately. Both suspend-to-RAM and suspend-to-disk (hibernate) are affected by a number of bugs which you can find on https://bugs.freedesktop.org/, in many cases with no reaction from AMD at all. Not even comments which suggest that they attempted to reproduce this issue internally.

Basically first Guest's issue is not suspend, he just wants to use the GPU on a living OS before any suspend attempt. By the way, I agree with you on the last part: there is no comments suggesting that they attempted to reproduce this issue internally, and we even doubt they have the hardware to reproduce the issue.

How about just staying with a working LTS kernel. This helped me with my fury

There is no working LTS kernel for that GPU yet. And about the Fury, I myself bought an R9 390 because at this time the Fury experience was known to be awful.Michael called it a “disaster”, there was no proper support on both open and closed source driver side. That's also why I bought a GCN2 GPU instead of GCN3 GPU at this time, because GCN3 was not ready months after the hardware was on sale, buying the most powerful GPU from the previous generation looked like the safest option, my bad it was not: the Fury is now among the best supported GPU around there…

I have a R9 290 (basically the same thing) with amdgpu+radeonsi+radv and I don't encounter any problems with that at all. Using the DC/DAL drivers causes problems, but I have no use for that anyway.

We know that the R9 290 does not face the issues the R9 390 is facing. We know they are basically the same things on the hardware side, but we also know the R9 390 is broken on Linux. If you only have an R9 290 you don't know what it is to have an R9 390 and you can't talk for the R9 390.

We not only faced system hang, we also faced that:




The R9 390 on linux story is a very sad story. And R9 390 owners like myself know how to report issues and to compile kernels. Like I said, I myself wrote a kernel patch to workaround the issue. I also wrote a systemd fake service to workaround the issue. My kernel patch is just there to prevent the GPU hang occuring before systemd does it. I even got a private message from a Feral employee to thank me for my systemd workaround so he can get his workstation up and running at work thanks to myself.

Basically, the current status on that GPU is that we can run it with all his features if we set special kernel boot option in GRUB. There is not “out of the box” support yet. It means you can't install a distro using a livecd on a machine with an R9 390 yet, because the stock kernel will hang the machine in the middle of the installation process.

I even faced visual corruption and crashes last month, not using the latest kernel but their latest amdgpu driver from their rocm stack (I currently use their rocm stack with a stock amdgpu kernel module).

Michael posted an article about that problem more than one year ago, titling at this time that “Some AMD Grenada Cards Have Been Borked On The Open-Source Driver For 2 Years“. And you know what? People started to play the conspirationist game, saying things like “Phoronic launched some anti AMD strategy last days. It is known for propaganda articles”, others just wanted to play the hide-the-truth game, saying thins like “Michael should add a Dislike button as well”. Yet at this time there were people telling that this was “completely in contrast to their experience with opensource amd driver and others quoting the 290. It looks like some people are just denialists on this topic.

You know, I'm very grateful toward AMD, I now have a complete open source kernel/mesa/opengl/dx9/vulkan/opencl stack thanks to them. But I unfortunately just bought the only one GPU that has bad support. Btw, the workaround is easy and easiest than the ugly quircks I have to do to get my Nvidia GPU working on my laptop, not saying that NVidia GPU is performing worse than the Intel CPU for OpenCL compute. Even with that R9 390 bad support, AMD is still a winner.

So, yes, AMD desperately need to hire someone to “debug issues, and engage with the open-source graphics development community”, yes, please, yes!

When I got that message from a Feral guy thanking me for the support I provided for the R9 390 GPU, I was proud, but that's not my job.

[dungeon]

AMD is looking for someone to co-ordinate with distributions and related free software projects whichi does require some people-person skills.

I am not sure what needs to be coordinated more, they should produce drivers for their products and that is pretty much it.

They already have devs using different big free distros, so i am sure they understand what happens in these. On the other hand builds from AMD site handle professionals, enterprises, embedded... so it sound to me that nearly everything is covered.

Only some users are not happy by stability of development, but that is expected as development can't be always stable by its nature

Maybe users want AMD to draw them Q1/Q2/Q3/Q4 recipes like Intel do Is that really needed? I think it is known that you have 4 stable mesa releases annually, so most users who wanna stability should stick to track that

It is most problematic to handle gamers, on Windows for consumer gamers (with cards only, not APUs) they do 30ish builds annually, so that is something like like 10 day git checkout on average Day to day gamers are most problematic to handle anyway

On the other hand non day2day gamers and PRO operate again mainly on Q1/Q2/Q3/Q4 bases On Linux for these if not using distro kernels, it is generaly advised to use longterm kernels anyway, not every short term stable releases.

Not sure I could do it since I don't like people and specially not some.

Well, ignore them if you can. There are always trolling users, but also trolling developers - these usually likes to roll, but also have ability to never do anything right. That is why we create rules and standards needed to follow, on the other hand trolls even that take too much seriously

Trolls are easy to fight, just fight them with their own weapon. As they ignore you, then you just ignore them. Or just link them to read some rules and standards, they will cry and to start to be worse and again and again and again

[finalzone]

AMD definitely needs more developers for the amdgpu driver. The latter just needs more refinement.
OpenCL 2.0+ from ROCM needs standardization on all GCN.

[illwieckz]

so, my comment with plenty of references was just dropped?