Trying Out The Radeon VII On Ubuntu 19.04 As Well As Linux 5.1 + Mesa 19.1

[Venemo]

And no, it's not hardware issue, because it works with llvmpipe.

llvmpipe is software rendering, so it renders using your CPU, not your GPU. "works with llvmpipe" means that it works without the GPU.

It is possible that you either have a revision of that GPU model which was not tested by the driver team (similarly to what happened with the Sapphire RX 590 earlier reported on Phoronix), and thus has bugs. It is also possible that you have a hardware defect. Hard to say. Consider filing a bug on freedesktop and/or pinging the devs in the #radeon channel on Freenode to get some help on how to diagnose what the problem is.

[blackiwid]

Could you please stop claiming that the free drivers are bad because Ubuntu has big problems?
It's like saying cars are bad because the streets in one country are bad.
It's a test about Ubuntu only, one if not the most horrible distro for free driver support.

So 99% sure it's the distro, because usually you don't have such big regressions in Mesa or free drivers itself.

I even called Ubuntu sometimes Nvidia Linux, because it brings so old kernels and not updates them which is horrible for free drivers but good for Blobs like the Nvidia Blob.

So don't judge the free drivers with "Nvidia Linux"!

So could it be that like you say the AMD drivers are horrible and there were hard regressions, sure everything is possible, is it likely? No, 99% sure it's what Michael test, Ubuntu.

And AMD can't fix how bad Ubuntu is, they only can work on upstream, when Ubuntu fails to deliver a good upstream experience because they use Server kernels on Workstations and some questionable or underpaid 3rd party people try to "backport" some upstream stuff, of course that is not trustworthy.

So as long as he does not test a current Fedora his findings are pretty much worthless or clickbait. It's like installing Windows XP and testing to install the newest graphics drivers... and take that as proof how bad the drivers from that companies is.

[theriddick]

Well I would recommend people use ARCH for testing so they can grab the latest stuff off AUR if needed.
ARCH repositories are kept up to date pretty fast whereas I can't say the same about ubuntu.

I'm using Antergos KDE myself, pretty good overall, I did have a blackscreen issue with NVIDIA drivers once but that was because a newer kernel came out and it didn't grab the headers which nvidia need or blackscreen/boot issues.

[mv.gavrilov]

Michael, use Fedora. I am has Radeon VII card and it work on Fedora out of box.

[aldieb]

I have had random hangs with my Radon VII but nothing as reproducible as in the article. The issue seems to have gone or got much better after I completely removed ROCm from the system. Might be worth a try for anyone who got similar problems and have ROCm installed.

[theriddick]

Wouldn't be surprised those people suffering GPU crashes is due to extremely relaxed fan/cooling curves under Linux (or not working correctly). I've seen that happen before.

A way to test is set fan to 100% then do testing, not ideal but useful for determining if heat is the issue.

[ThoreauHD]

I'd like to see a 18.04 with proprietary driver comparison, to eliminate a hardware failure.

[illwieckz]

I would really like to see them stepping up their game, because we really need [AMD] to put pressure on nvidia.

We really need AMD to give us great GPU with open drivers.

We don't need any other pressure than the one that would make NVidia opening drivers.

You can't expect AMD to put pressure on NVidia if you don't buy AMD.

AMD is a GPU maker you can buy GPU from, not a way to make you buy more NVidia.

[beniwtv]

All these users claiming it's perfect don't know what they are saying or they clearly don't use their computers enough.

<sarcasm>You discovered me! I don't actually use any of my 3 PCs with AMD CPU + AMD GPU, I got the Radeon VII just for show!</sacrasm>

Now on to a more serious note: Every PC is different, even if it has the same components. How we use our PCs is different, so the way we use the hardware can be quite different. In general, that often leads to vastly different experiences across different users.

We can't simply say "It works for me, you are wrong!". Neither can we say "It doesn't work for me, so it works for nobody and you all are lying!"

As a software dev myself, I can relate that it can often be very hard to reproduce and debug a problem if you're not in front of the failing computer yourself. And what we can't reproduce, we generally can't fix. Sometimes you can take a guess and "win", but with something as complex as a GPU driver stack, good luck I'd say.

In Michael's case, he already wrote AMD couldn't reproduce his problem, so it's not like they're ignoring it. And out of experience, they are also not ignoring the fd.o bugtracker, there's just lots of issues, not everything is reproducible or affects everyone. So they kinda have to prioritize things by severity a bit.

[xiando]

There's a report on newegg of a similar repeated failure after an overheating event. User feels it was a faulty card, had to RMA.

From the article:
>which is a pity since on launch-day the support was working out well when fetching the latest code at the time.
Ruling out the card currently being faulty after some kind of .. event should just be a matter of Michael re-testing it with the exact same software and hardware he used for the launch-day testing. If that configuration which previously worked still works then cards probably fine, if that suddenly throws the same kind of errors then it's time to take a good long look at the card.

Windows-infecting a machine and using that to test the card may also be a worthwhile idea.

I am curious to see how this plays out regardless of that the issue is since quite a few AMD linux developers visit this site from time to time.