Radeon ROCm 2.2 Released With Vega 20 Optimization, Caffe2 Multi-GPU Training

[nuetzel]

I'm not sure if Tumbleweed would work with our closed opencl stack... it's possible, but a safer bet would be installing the SLED drivers on Leap.
E.g. AFAIK, SLE 15 drivers would work on Leap 15.0, as long as you use the --no-dkms option in the installer as the dkms is not designed to work on Leap.

Something like this using 18.50:
./amdgpu-install --headless --no-dkms --opencl=pal

I'm 'the one' running 18.xx for ages over Tumbleweed on top of OSS for ages...

Although if someone is building ROCm for tumbleweed, that might be a better option.

But this do NOT work for Polaris - the firmware thing...

Addendum:
After Marek told us that Polaris (RX580, 8 GB) is working without PCIe atomics (even on PCIe 2.x) I was going with it and hoped even for ROCm. Yes, it is GREAT. Power usage is OK and @HD it offers enough force for mostly all use cases. Vega20 / Radeon VII is a BEAST, but I'll go after Navi if 4K/5K monitor prices went down and these resolutions became more casual and lower demanding for the gfx cores.

[Marc Driftmeyer]

I have the impression that the best OpenCL in Linux will be from AMD and Intel once karol land the NIR Clover backend and HMM is implemented on AMDGPU and i also suspect will be a lot less buggy and a lot quicker to fix quirks than RocM/AMDGPU-pro.

I might be wrong but i honestly believe this will be right based on the history of OpenGL and Vulkan so far

ROCm doesn't enable OpenCL on Blender. Only the AMD Pro Driver does that, and unless you are on a sanctioned distro the last viable version is 18.20.

[cb88]

ROCm doesn't enable OpenCL on Blender. Only the AMD Pro Driver does that, and unless you are on a sanctioned distro the last viable version is 18.20.

That's a function of the specific way Blender is using OpenCL that isn't ideal for running on ROCm.... It's being worked on https://blenderartists.org/t/blender...e-2019/1149152

https://wiki.blender.org/wiki/User:Jbakker/reports/Cycles_OpenCL_status_report_1

[AndyChow]

But this do NOT work for Polaris - the firmware thing...

Addendum:
After Marek told us that Polaris (RX580, 8 GB) is working without PCIe atomics (even on PCIe 2.x) I was going with it and hoped even for ROCm. Yes, it is GREAT. Power usage is OK and @HD it offers enough force for mostly all use cases. Vega20 / Radeon VII is a BEAST, but I'll go after Navi if 4K/5K monitor prices went down and these resolutions became more casual and lower demanding for the gfx cores.

Could you please elaborate? I have a RX480 8GB without PCIe atomics, using PCIe2.x. Are you saying you can get ROCm working? Right now I've been forced to use a RTX 2070. If I could get the RX 480 to accelerate my tensorflow training, I would be rather happy.

[nuetzel]

Could you please elaborate? I have a RX480 8GB without PCIe atomics, using PCIe2.x. Are you saying you can get ROCm working? Right now I've been forced to use a RTX 2070. If I could get the RX 480 to accelerate my tensorflow training, I would be rather happy.

"...and _hoped_ even for ROCm. Yes, it is GREAT." - Apart from ROCm on PCIe 2.x system without PCIe atomics. So NO.

[Meteorhead]

Boo hoo!

Very constructive, thank you.

[Meteorhead]

I have the opposite impression. Just installing the official video display driver from AMD on Windows is sufficient for using OpenCL for example with Blender 3D. Enabling OpenCL on Linux (again for the simple purpose of taking advantage of it in end-user applications) on the other hand feels quite confusing.

Well, my frustration stems from rolling driver installs, because "proper" OpenCL support and up-to-date graphics support are conflicting requirements. As we've discussed a few months ago, SPIR support (required for SYCL development) has been removed half a year ago, and yet it's still reported by the runtime as a supported extension. CPU support has also been dropped (cannot run my single-platform code on both CPU-GPU at the same time, I'd need to rewrite my code so it handles multi-platform synchornization properly and install POCL for my AMD CPU). It feels much like compute support falling apart. Features are never added, just removed. The reason for rolling driver installs is that I work by day and play by night, and Vermintide 2 crashes routinely with old the driver with SPIR+CPU support. So I install 18.2 every morning and install latest drivers every night.

This is not prime time driver support in my book.

[tuxd3v]

"...and _hoped_ even for ROCm. Yes, it is GREAT." - Apart from ROCm on PCIe 2.x system without PCIe atomics. So NO.

Well amdgpu was already working with RX580 without PCIe Atomics, at least on pcie3.0.. That is not new..

What could be new, is Rx 580 on pcie3.0 Without Pcie Atomics operations..like other cards..
In fact it should be already be working from the beginning..

Apart from that its nice to see that some APUs are getting some attention..

Because we don't have expensive cards to play games, and we don't have expensive cards attached to a display, hurting performance..

What we like is a APU, for CPU+ igpu attached to a display,
And for OpenCL dGPUs in headless mode..

This is the perfect setup..
Rx 580/590 fits very well here..
BUT the fact that they doesn't work on Rocm ...renders them useless garbage..

[vegabook]

Very constructive, thank you.

But there's a serious point here. I went through the same frustration as you, not on Rocm but on other Linux "first class citizen" server stacks where Windows was a distant second. Years ago but not that long ago. 2013 area. After 15 years of Windows. And after the initial pain, I never looked back. There comes a time where you have to explain to your bosses (or yourself) that you can't do your job properly without Linux.

Windows is primarily a front end technology while Linux owns "serious" compute. AMD has limited resources and is completely correct in prioritizing Linux. It's up to you to change, not them.

[bridgman]

For what it's worth we are working on bringing some of the ROCm stack to Windows. Won't be the same as the Linux implementation and not intended for scaling up to data center use but should be able to take advantage of ML framework and other ports to ROCm up to workstation level. Our thinking was that full equivalence for Windows was probably overkill in this case, but zero support was not enough either.

In the "lessons learned" department we started the HSA effort with a strong "Windows-first" approach but realized that Windows was not able to pick up core OS features quickly enough for us to use the same solution on both OSes. The Linux HSA implementation evolved into ROCm, and the Windows HSA implementation evolved into some user queue features to make graphics and workstation OpenCL perform better... but now we have a chance to circle back and make some of the Linux work available on Windows.