AMDGPU vs. Radeon DRM On Linux 4.13 For AMD GCN 1.0/1.1 GPUs

[Shevchen]

Okay, we learn, that certain cards still have wonky driver support on both sides. I wouldn't have expected such strong "jumps" forth and back between the drivers, so it seems we still have some regressions to fix on the OS drivers - the closed source blob however should fade out. Its still interesting to see how it perform better in certain scenarios.

Now for the "AMD charges several hundreds of dollars for broken drivers" point: Not on Windows and there they hold their promise of "fine wine". But of course this is Linux, but Linux also means: Open Source.

And here, I see the drivers in SUCH a good state, that I'm willing to buy an AMD card over an Nvidia card by now if I plan to use it primarily on Linux. The whole Vega "issue" has to be sorted out at some point - but I'm confident, that Vega will have a very good standing on Linux, once the initial support inculding DC lands.

Some quality of life changes like easier overclocking would also be welcome - but a workaround is just to flash the GPU-BIOS to the desired values. Nothing too bothersome compared to the usual Linux side-work I do. Flash and be happy - calibration has to be done either way (Windows or Linux), so no argument here.

[finalzone]

Isn't amdgpu.exp_hw_support=1 enough for GCN 1.0? It was on older Kernel versions. Or are these new options just for not needing to blacklist radeon anymore?

amdgpu.exp_hw_support=1 is no longer needed. Use amdgpu.si_support=1 radeon.si_support=0 instead as parameter so you don't need to blacklist radeon driver.

[bridgman]

Michael, thanks for running these tests. It does seem like we are coming up on time to flip the switch for CI although we need to check the APUs as well (which is why we have been working on the switch), but still some work to do on SI.

One option might be to flip just Hawaii over to amdgpu but it would certainly be cleaner to flip the entire generation. We have been doing some ROCm testing with amdgpu on Hawaii and Kaveri, and AFAIK that has gone pretty well.

Has anyone with Kaveri or Kabini tested with amdgpu recently and run into problems that would justify not flipping the switch for all of CI ?

[theriddick]

Yeah its a bit all over the place with support features and regressions, I surely hope that once AMD sorts out their DC/DAL stack and merges it (or is allowed to) that we will get some more unified features and support. I'm also wondering if the Fury cards suffer regression on the radeonsi driver like how the 290 cards do?¿

[bridgman]

AMD graphic stack is completely weird, how do guys at AMD expect us to maintain 3 distros with different drivers.

1. Mesa + radeonsi ( gaming )
2. Amdgpu pro ( workstation )
3. Rocm ( open compute )

We don't - the core ROCm support has been integrated into AMDGPU-PRO starting with 17.20 release (initially used for OpenCL only but that's a function of validation bandwidth), and we are in the process of pushing the same code upstream which gets it into the all-open Mesa+radeonsi stack.

We are still recommending the ROCm stack for large scale HPC (and will probably continue to do so) but HPC-specific out-of-tree drivers have always been the norm for HPC.

even their open source support is fragmented between rads and (coming soon) Vulcan.

They are wasting resources everywhere and still we wonder why there isn't HDMI audio support.

Quick reality check - we write a Vulkan driver, we start work on open sourcing it, Dave & Bas start working on a different driver and *we* are wasting resources ?

Just to be clear, Dave started work on radv for all the right reasons and radv may still end up being the primary Vulkan driver depending on how efficiently we end up being able to integrate community contributions back into our in-house driver, but blaming *us* for having two different drivers seems like a bit of a stretch.

There are still a number of features that need to be added to radv plus the ongoing effort of supporting new HW, so "dropping our driver for Linux and going with radv" is not the obvious slam-dunk that people would like to think... it's one of those nasty "both options suck in different ways" things instead.

[Michael]

Michael, thanks for running these tests. It does seem like we are coming up on time to flip the switch for CI although we need to check the APUs as well (which is why we have been working on the switch), but still some work to do on SI.

One option might be to flip just Hawaii over to amdgpu but it would certainly be cleaner to flip the entire generation. We have been doing some ROCm testing with amdgpu on Hawaii and Kaveri, and AFAIK that has gone pretty well.

Has anyone with Kaveri or Kabini tested with amdgpu recently and run into problems that would justify not flipping the switch for all of CI ?

I can try (time permitting) to run some Kaveri AMDGPU vs. Radeon comparison shortly... Feel free to ping me in a week or so if you don't see such article by then.

[leipero]

....It wouldn't surprise me if r600 is a higher priority than that....

As an r600 user, I can tell you that drivers are really good, the only problem with r600 (at least for my GPU) is when using gallium-nine, in some situations with some shaders it gets (quite big) performance issues, and from what I've read, it's not actually driver problem (sort off...), it's because loop unrolling isn't implemented in LLVM for r600, and nine bypasses GLSL, for newer GPU's it isn't a problem because LLVM unroll them. But I'm realistic, and you can't expect people to bother now for such low-use scenario for what is esentially 7+ years old GPU.

[boxie]

Yes please flip the entire generation to AMDGPU. this sounds very good.
And yes ROCm on AMDGPUs are very important for good OpenCL performance.

I tell you some crazy story from today my brother want to buy AMD GPU cards for 7000€ to let me do ethereum ETH crypto-currency mining.
I hope the AMD RX VEGA XTX water cooled version comes out at the end of the month because i will not buy older hardware than this.

So I hope Open-Source (ROCm) OpenCL support is in a good status

ROCm is new and if I recall, the devs initially did not have a mining workload in their testing - so mining on a ROCm driver was not as good - this was a month or so ago though, since then there has been a lot of GPUs mining hard, so hopefully the ROCm devs have got some mining workloads going.

[johnny99]

I've been using AMDGPU on kaveri for a a long time. Six months? Other than things getting messed up when a bad patch went in for initializing uvd I've never had a problem.

[mitch074]

I should try running my HD7770 from a vanilla kernel + AMDGPU again, to make sure all bugs/regressions remain gone. I'm not going to use it regularly before DAL/DC is integrated, I'm using sound over HDMI with it.