Christening a RX-460 on Debian/stable

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666
Topic 202535

Most of my GPUs are ancient, due to be deprecated (HD5450, HD6450). The 2 newer ones are problematic.

The newest is a RX-460 (AMD Polaris). On Debian stable, this means installing the 4.7 kernel in order to be able to use the amdgpu module. In so far as I have a graphics display, it works. Some operations are horribly slow, and looking at temperatures the card is in idle all the time.

I am not fluent in BOINC or OpenCL, but I am an old time number cruncher (mostly FORTRAN). In trying to get all the dependencies right, I had a job or so downloaded from SETI, and similar from PrimeGrid. This was enough to check binaries with ldd to see what libraries are missing. This also told me that libclc doesn't compile OpenCL programs.

The version of libclc in stable or backports, is the same, and doesn't work. As near as I can tell, the only other version anywhere in Debian, isn't new enough to have all the polaris code in it. And it requires llvm-3.9 (and clang-3.9) in order to compile. And llvm-3.9 isn't in Debian, because it generates bad code for some architecture (armhf?).

Compiling llvm-3.9 requires a newer cmake than stable or backports has.

So, I compiled cmake (to /usr/local), and then I compiled llvm and clang, installed in /usr/local. And then I downloaded libclc from 20161030. It compiled without error (which is not a guarantee it works). But, manually installing the various components and removing the standard libclc without disturbing a bunch of other things concerned me. So, on the basis of libclc in deb source tree from Debian stable and the one in Debian experimental, I have a sort of Debian source tree that has a bunch of lies in it (like it requires llvm-3.8, when I have llvm-3.9 in /usr/local and is the true requirement).

It seems to have compiled everything, but debuild died before building packages because a symlink involving cypress-r600--.bc failed. Hopefully it won't take too long to figure out how to complete the lies, so that I get a package with everything in it.

The version assigned to this frankenstein library I am building, is just a little bump on the Debian/stable package. Hopefully this makes installing it (as newer) or putting the original one back in easier (if I need to at some point).

Are there testing things I should do before a reboot with the new libclc in place? What about after a reboot? Is there some kind of test OpenCL/BOINC code I can run, to see if this RX600 is working and test it?

Thanks (from Dawson Creek, BC, Canada - where the Alaska Highway begins).

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

After a few passes of debuild

After a few passes of debuild crash, edit a file in .../debian, start debuild and then telling debuild to ignore lintian problems, I built a deb of libclc which theoretically should be able to compile an Einstein BOINC job.

 

So, I allowed BOINC to run GPU jobs again, and I got a bunch (5?) of jobs which failed almost immediately again.  Same error code (11), which I gather correlates to libclc was unable to compile.

 

Is there some way to find out more about what is happening?

 

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513,211,304
RAC: 9

Gordon hi, welcome to

Gordon hi, welcome to E@H.

 To be honest i don't know where to start here, but some suggestions may help.

On Debian stable, this means installing the 4.7 kernel in order to be able to use the amdgpu module. In so far as I have a graphics display, it works. Some operations are horribly slow, and looking at temperatures the card is in idle all the time.

 Can you be specific about where you are getting the amdgpu module and why this dependency on 4.7?

You are in effect running the Mesa open source drivers as best i can tell.  The support for the latest generation AMD GPUs is somewhat leading edge, keep an eye on www.phoronix.com

 I guess you are running Jessie/stable, i think i might strongly suggest trying testing or unstable before building new system libraries - you may have already tried this. 

 Are there testing things I should do before a reboot with the new libclc in place? What about after a reboot? Is there some kind of test OpenCL/BOINC code I can run, to see if this RX600 is working and test it?

clinfo is usually sufficient - however boinc client is detecting the via the OpenCL libraries, that is obvious from the error messages for example here   https://einsteinathome.org/task/584345747

Looking on my system (RX-480)  ldd shows for the BRP4G v 1.52 using the amgpu-pro drivers on Unbuntu 16.04 (kernel 4.4)

einsteinbinary_BRP4G_1.52_x86_64-pc-linux-gnu__BRP4G-Beta-opencl-ati:
     linux-vdso.so.1 =>  (0x00007fffdb9fb000)
     libOpenCL.so.1 => /opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007fe1d362d000)
     libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe1d3410000)
     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe1d3106000)
     libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe1d2d84000)
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe1d29bb000)
     /lib64/ld-linux-x86-64.so.2 (0x0000563792d4b000)
     librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe1d27b2000)
     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe1d25ae000)
     libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe1d2398000)
 

You'll notice the OpenCL library name. located oin /opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1

Is amdgpu-pro an option for you (not mesa) ?

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

Thanks for the

Thanks for the reply.

 

amdgpu module is not in the stock (3.16) kernel.  For stable/jessie, it is only (or lowest version where available) is 4.7, which is in jessie-backports.

 

Yes, it is the Mesa drivers I am using.

 

I don't mind building things, I've been around Linux since 1.2.13.  I've installed some big packages from source over the years.  Updates get to be problematic with self-installed stuff.

clinfo is giving the same error (11).

> ERROR: clBuildProgram(-11)

ldd is finding all the libraries it needs.

 

I have been using Catalyst on another machine (needing to switch to Crimson for that one), but the impending deprecation of so much hardware by AMD was incentive to see if the mesa support would work.  I guess I'll read more at phoronix, and see if there are hints from there.  I have worked with lots of different stuff, including kernel drivers in the past (a token-ring driver comes to mind), but it seems so clumsy to debug some of this stuff.

 

In the mean time, back to trying to get an A10 APU and R7-250 working with Crimson.  :-)

 

Computers are so much fun.  :-)

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

Hmm.  I hadn't tried clinfo

Hmm.  I hadn't tried clinfo enough on this.  Running strace on clinfo is interesting.  clinfo finds "files" at times, often after looking a lot.  And then some distance down the trace, it does the same thing all over again.  It seems to be using the pipe-radeonsi facility.

 

Just before the failed attempt to build, I see a fork and a call to llvm-3.8.  As I understand things, it should be calling the version in /usr/local/bin which by llvm-config is 4.0.0 (as is clang).

 

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

The llvm I manually compiled

The llvm I manually compiled and installed (in /usr/local) does not have a libLLVM.so.  The only libLLVM.so on the system, is the 3.8 version from jessie-backports (mostly here to fool some dependency stuff).

 

Checking the filesystem where I compiled LLVM, there is no libLLVM.so (or versioned).

 

I see a bug report (at  llvm.org) going back to 2013, where the configure system has a --enable-shared switch.

 

Hmm, looks like I need to rebuild LLVM, missing a define for this.  And maybe I can build everything properly this time.  Well, I got fewer errors on rebuilding LLVM, clang, etc (mostly in OpenMP), but there is still no libLLVM.so (or similar versioned).  I've got to go be a driving instructor for a while.

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

Oops, I guess it helps if you

Oops, I guess it helps if you look in the correct tree.  :-)

 

There is a libLLVM-4.0svn.so which is built.  Just a tiny library at 54 MB or so.

 

I guess set up symlinks of libLLVM.so.4.0, libLLVM.so.4 and libLLVM.so should work after I install it.  And then run the ldconfig or whatever it is called.  But I still need to go instructing for a bit.

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

I had some scribbles here,

I had some scribbles here, refreshed the page, and they are gone.  Oh well.

 

It seems likely that I haven't replaced enough.  There are 2 clinfo programs available in Debian/stable.  One of them if from amd, and in part relies on binary blobs.  This  one specifically calls for LLVM-3.8.  The other one, goes through mesa and eventually it too calls LLVM-3.8.

 

So, I probably need to replace mesa.  Documentation for mesa is a little lacking as to what you download, and what you need.  But, both the git and the mesa-13.0.0 tarball fail to compile at the moment with LLVM-4.0.  The errors all have to do with LLVM attributes, so I will guess there is an include file in LLVM which changed.  I don't know enough about LLVM at the moment to fix it.  Will someone else fix it, probably.  Soon?  I don't know.  Whetehr it was the right decision or not, I had decided to compile mesa with vulkan drivers (it is not obvious that those drivers exist in mainline mesa), with the radeonsi gallium driver (as well) and due to a configure error, with egl_platforms=drm.

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

I see that some mesa

I see that some mesa (related?) developer has noticed the API change in LLVM (today?), and filed a bug report on it.  So, perhaps soon mesa will compile again?

 

Gordon Haverland
Gordon Haverland
Joined: 28 Oct 16
Posts: 20
Credit: 362,929,904
RAC: 862,666

I have been updating the git

I have been updating the git archive and checking, and today I see that mesa compiles to completion.  I would imagine this is going to result in the creation of a new tarball of the archive, but as of this time, it hasn't happened.

 

jay
jay
Joined: 25 Jan 07
Posts: 58
Credit: 44,760,830
RAC: 12,895

Greetings!I have much more

Greetings!

I have much more luck just using the Debian (Ubuntu in my case) pre-compiled binaries in the

"BOINC" package. There is a meta package that gets the Manager and the Client together with all of the sources at a correct level.

When I tried to compile, I could not get the GPU driver, Mesa, and the kernel levels to agree.

Years ago, I saw a posting from a guy from Italy that explained the difficulties in getting dependencies to match.

 

You have *much* more patience than me. I gave up ahter 3 weeks and went to the packages.

If you got it to work, please post your status. I'm interested!!

 

Jay

 PS, I am using HD6570, Low wattage usage.

But only 1/3 the speed of some of the larger NVIDIA.

Happy Crunching!    Happy Compiling!

 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.