Building on Arm Linux

Message boards : Number crunching : Building on Arm Linux
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1927671 - Posted: 1 Apr 2018, 10:51:10 UTC

I am trying to build sah on Arm Linux. The ultimate goal is to enable OpenCL support for the Odroid XU4 single board computer equipped with two Mali-T628 GPUs. Note that this thread originates from the respective "Mali-T628 GPU" thread. But first I need to get the stock client built without modifications.

Specifically I am trying to build the v8 stock client on Ubuntu Linux for the armv7l architecture (Exynos 5422 32-bit with 8 cores). After having failed with some quick attempts I am ready to do the proper way and start from scratch. In this regard I am having a number of questions to get me started:

1. Is there any documentation available on how to build sah from source? I have not been able to find anything comprehensive yet. I am familiar with the GNU autoconf build system. What I am searching for is information on the 100 specific options and parameters.

2. Which boinc and sah versions should I start with? I am looking for the latest stable versions that are known to work together. Ideal would be tags/revision numbers for the git and svn repositories.

3. Are there any build scripts available to simplify the process? I noticed that such scripts exist for the android platform.

4. Is there a development mailing list, irc channel or similar where I can ask my questions? This forum seems only partially suitable. I have seen there is a mailing list for porters. However, I was not able to subscribe.

Answers and hints to any of these questions are highly appreciated.
ID: 1927671 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1927677 - Posted: 1 Apr 2018, 12:25:05 UTC - in response to Message 1927671.  
Last modified: 1 Apr 2018, 12:28:48 UTC

Until someone with more fresh knowledge steps in try to look through this thread:
http://setiathome.berkeley.edu/forum_thread.php?id=80954&sort_style=6&start=0(Linux (ARM processor) app and alternatives)
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1927677 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1928075 - Posted: 5 Apr 2018, 9:27:13 UTC - in response to Message 1927677.  

Thanks Raistmer. I have been able to build the seti@home application following instructions in the thread you provided. I also get an error message at the end of compilation, but the arm binary is there. These are the versions I have used for building:

FFTW: version 3.3.7 from project home page
boinc: version 7.6.31+dfsg from Ubuntu repository
seti@home: revision 3304 from subversion repository

I have been able to install the binary and it seems to be running properly. Need to see still whether the performance is identical to seti@home v8.06 stock application. In the next step I am going to try again building from optimized source.
ID: 1928075 · Report as offensive
W3Perl Project Donor
Volunteer tester

Send message
Joined: 29 Apr 99
Posts: 251
Credit: 3,696,783,867
RAC: 12,606
France
Message 1928076 - Posted: 5 Apr 2018, 10:10:23 UTC - in response to Message 1928075.  

You can use the benchmark tool to test :
KWSN-Bench-Linux-MBv7_v2.01.08
ID: 1928076 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1929073 - Posted: 9 Apr 2018, 19:41:14 UTC - in response to Message 1928075.  

Making progress slowly, but making progress at least. After having successfully built the stock application on my Odroid XU4 board under Ubuntu Linux I restarted my attempts to compile the optimized source base (AKv8 application in sah_v7_opt branch). This is how I have done:

1) Convert line breaks
Line breaks of the optimized branch are dos style and not auto-converted to linux style during checkout. I had to manually convert all text files using the dos2linux command line tool. I propose to set the "svn:eol-style=native" attribute for the whole branch directly in the SVN repo in order to avoid this problem.

2) Setup the autoconfiguration system
After having compiled the stock application I noticed that there is also a _autosetup script in the directory of the AKv8 application. Only the executable bit was not set, which was simple to fix. The script completes without errors.

3) GCC multilib packages
Based on the error messages produced by the "configure" script I found out that I have to install the packages "gcc-multilib" and "g++-multilib". Note sure what it does, but it reduces the error messages/warnings I receive during configuration.

4) Locating OpenCL headers
Seti@Home expects to find OpenCL headers in /usr/include/OpenCL whereas headers are installed under /usr/include/CL on my system. Simple to fix by creating a symbolic link:

$ ln -s /usr/include/CL /usr/include/OpenCL

5) Configuring the build system
Ready to configure the build system. This ist the command line I have come up with:

$ ./configure --disable-server --disable-graphics --disable-shared --enable-client --enable-static-client --enable-dependency-tracking --enable-static --with-boinc-platform=armv7l-unknown-linux-gnueabihf --with-ssl --enable-bitness=32 --enable-arm_neon --enable-fast-math --enable-comoptions CXXFLAGS="-I./client -I./../src" CPPFLAGS="-DUSE_FFTW -DUSE_OPENCL -DOCL_ZERO_COPY -DASYNC_SPIKE -DSETI7 -DSETI8 -DOCL_CHIRP3" LDSTATIC="/usr/lib/arm-linux-gnueabihf/libssl.a /usr/lib/arm-linux-gnueabihf/libcrypto.a" LDFLAGS=" -ldl -lm -lz -static-libgcc -static-libstdc++" BOINCDIR=" ../../boinc"

The script completes without errors. This already one step further than I got before. There is hope.

5) Building the Seti@Home application
Finally I tried to built the application:

$ make
make -s all-recursive
Making all in client
g++: error: unrecognized argument in option ‘-march=armv8’
g++: note: valid arguments to ‘-march=’ are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6kz armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv7ve armv8-a armv8-a+crc armv8.1-a armv8.1-a+crc iwmmxt iwmmxt2 native
Makefile:1292: recipe for target 'seti_boinc-main.o' failed
make[2]: *** [seti_boinc-main.o] Error 1
Makefile:522: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:448: recipe for target 'all' failed
make: *** [all] Error 2

And this is where I am currently stuck. The -march setting is obviously incorrect. It should be "-march=armv7" for the Exynos 5422 architecture used by the Odroid XU4 board.

I have checked in configure.ac: These are the tests being run:

AM_CONDITIONAL(ARMV7, [test -n "`echo ${target} | fgrep -e arm -e gnueabihf`"])
AM_CONDITIONAL(ARMV8, [test -n "`echo ${target} | fgrep -e arm -e gnueabihf`"])
AC_MSG_NOTICE( ARMV7 = $ARMV7 ARMV8 = $ARMV8 )

Interestingly they are identical for the armv7 and armv8 platform. Can that be? And they both fail. The target is auto-detected and $target set to " armv7l-unknown-linux-gnu". The strings $ARM7 and $ARMV8 remain empty. In addition the strings ARMV7_FALSE and ARMV8_FALSE both are defined (according to config.log).

I am uncertain now what to do. Is this an error in the configuration script? Or is there still something wrong with the parameters given to the configure script? I am grateful for any hints.
ID: 1929073 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1929074 - Posted: 9 Apr 2018, 19:41:44 UTC - in response to Message 1928076.  

Thanks for the hint. Not there yet :-)
ID: 1929074 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1929206 - Posted: 10 Apr 2018, 7:28:41 UTC - in response to Message 1929073.  


I am uncertain now what to do. Is this an error in the configuration script? Or is there still something wrong with the parameters given to the configure script? I am grateful for any hints.


Congrats for going so far!

Apparently some misconfiguration takes place.
I would start from fixing particular compiler error (maybe it's not "correct" way but inherently I don't trust "too smart" tools and *nix autoconfigure scripts that "know better" what capabilities your system has like this armv8 issue fall into that category).

So, attempt to establish from where exactly -march=armv8 option came, why compiler string gets this option.
Find place where it assigned and hack it to manually assign armv7 or native. No matter what autoconfig thinks it should be.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1929206 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1930360 - Posted: 16 Apr 2018, 19:56:13 UTC - in response to Message 1929206.  
Last modified: 16 Apr 2018, 20:03:58 UTC

I have again made some progress. I realized that tests for the armv7 and armv8 platform where not negative, but in fact both positive. I have now adjusted the tests in configure.ac as follows:

AM_CONDITIONAL(ARMV7, [test -n "`echo ${target} | fgrep -e armv7 -e gnueabihf`"])
AM_CONDITIONAL(ARMV8, [test -n "`echo ${target} | fgrep -e armv8 -e gnueabihf`"])

The arvm7 platform is now correctly detected and the -march flag properly set, which brings me to the next error message, when trying to compile the client with $ make all:

In file included from main.cpp:91:0:
analyzeFuncs.h: At global scope:
analyzeFuncs.h:77:9: error: ‘__m128’ does not name a type
typedef __m128 vFloat;
^
analyzeFuncs.h:78:9: error: ‘__m128i’ does not name a type
typedef __m128i vUInt32;
^
analyzeFuncs.h:79:9: error: ‘__m128i’ does not name a type
typedef __m128i vSInt32;
^
analyzeFuncs.h:80:9: error: ‘__m128i’ does not name a type
typedef __m128i vUInt8;
^
analyzeFuncs.h:81:9: error: ‘__m128d’ does not name a type
typedef __m128d vDouble;
^
Makefile:1292: recipe for target 'seti_boinc-main.o' failed
make[2]: *** [seti_boinc-main.o] Error 1
Makefile:522: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:448: recipe for target 'all' failed
make: *** [all] Error 2

The file analyzeFuncs.h is a header file in the client sub-directory. If am not mistaken, the missing types are related to SSE code for the x86 architecture, which is not available on arm. I have compared analyzeFuncs.h of the sah7_opt branch to the stock client and it seems that it has been heavily pimped. I suspect the code simply does not support arm neon architecture yet?

Adjusting the code for arm neon is definitely beyond my skills. So unless this can be fixed with a few compiler flag settings or adjustments in the source code I believe I have reached the point where need to give up.

Maybe a last idea: I have come across this web page [1] during some searches. Could it make sense to emulate SSE on ARM using simde library instead of rewriting the code?

As always any hints welcome! I am running out of ideas here.

[1] https://github.com/nemequ/simde
ID: 1930360 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1930576 - Posted: 17 Apr 2018, 21:58:56 UTC - in response to Message 1930360.  


The file analyzeFuncs.h is a header file in the client sub-directory. If am not mistaken, the missing types are related to SSE code for the x86 architecture, which is not available on arm. I have compared analyzeFuncs.h of the sah7_opt branch to the stock client and it seems that it has been heavily pimped. I suspect the code simply does not support arm neon architecture yet?

Adjusting the code for arm neon is definitely beyond my skills. So unless this can be fixed with a few compiler flag settings or adjustments in the source code I believe I have reached the point where need to give up.

Maybe a last idea: I have come across this web page [1] during some searches. Could it make sense to emulate SSE on ARM using simde library instead of rewriting the code?

As always any hints welcome! I am running out of ideas here.

[1] https://github.com/nemequ/simde

Thanks for link and description of your experiment.
I never attempted to build opt codebase for ARM so need some time to evaluate all this,
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1930576 · Report as offensive
Profile tullio
Volunteer tester

Send message
Joined: 9 Apr 04
Posts: 8797
Credit: 2,930,782
RAC: 1
Italy
Message 1930670 - Posted: 18 Apr 2018, 13:00:29 UTC

HPE (former HP) is donating three Apollo superminicomputers with ARM processors to three British Universities. OS is SuSE Linux Enterprise Server.
Tullio
ID: 1930670 · Report as offensive
MarkJ Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 17 Feb 08
Posts: 1139
Credit: 80,854,192
RAC: 5
Australia
Message 1930678 - Posted: 18 Apr 2018, 13:26:28 UTC

Have you read https://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2275?

As you will see we had an ARM app done with the help of Claggy and Tom Rinehart so the existing one should simply work out of the box and use neon if the CPU supports it. They may be able to assist you with compiling your own version.
BOINC blog
ID: 1930678 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1930935 - Posted: 19 Apr 2018, 19:48:48 UTC - in response to Message 1930678.  

Thanks for the hint. Stock app actually works perfectly on my Odroid XU. Performance is also fine. I get about 3 times the credits of a Raspberry Pi 2. Only the GPUs do not get any work to do. What I am trying to achieve here is compiling the optimized branch with OpenCL support and modify the code where necessary. Apologies for not being more specific in the subject. The Exynos 5422 SoC has two Mali-T628 GPUs which support OpenCL 1.1. So in theory it should be possible to have them supported.
ID: 1930935 · Report as offensive
Langweiler

Send message
Joined: 24 Feb 17
Posts: 15
Credit: 293,469
RAC: 0
Germany
Message 1930944 - Posted: 19 Apr 2018, 20:23:28 UTC - in response to Message 1930360.  

Since it cannot get worse I have simply commented out the type definitions making use of SSE intrinsic types in analyzeFuncs.h. Surprisingly that does not cause any new errors, but compilation of analyzeFuncs.cpp seems to complete successfully.

Instead I am getting the following new error:

analyzePoT.cpp:3205:24: error: ‘tempPulsePoT’ was not declared in this scope
retval = find_pulse(tempPulsePoT,

Reason is that the pointer tempPulsePoT is defined in a conditional block depending on USE_TRANSPOSED_POT, which again depends on USE_PPC_OPTIMIZATIONS or USE_I386_OPTIMIZATIONS. Both are not defined.

In order to fix I have simply added the declaration of tempPulsePoT to the else statement and the code continues to compile. Of course I do not know whether the code is still functional or I just broke it.

Of course I am getting another error:

lcgamm.cpp:194:18: error: ‘f_recip’ was not declared in this scope
c = an*f_recip(c)+b;

Again the function f_recip is defined in a conditional block depending on __VEC__ or __SSE__. Both are not defined and as a consequence f_recip is missing. This time I am not certain what to do. Need to think about it first. As always any hints welcome.
ID: 1930944 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931000 - Posted: 20 Apr 2018, 7:12:17 UTC - in response to Message 1930944.  

Well, you are on SSE SIMD code path currently so some NEON SIMD analogue should be provided....
Perhaps fixing path route selection (to not step on SSE one) would be better than dealing with all SSE-based functions one by one.
It means to step back to _m128 errors and find why those lines are reached.
Not sure opt codebase contains non-SIMD path at all though need more reading on that point.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931000 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931002 - Posted: 20 Apr 2018, 7:35:40 UTC - in response to Message 1930944.  

f_recip() used only for lcgf() so for now you could try to replace SIMD lcgf by its double scalar version:
/* Log of the compliment of the incomplete gamma function
 * log(1-P(a,x)) valid only for (a+1)<x
 */

double lcgf(double a, double x) {
#ifdef USE_MANUAL_CALLSTACK
  call_stack.enter("double lcgf()");
#endif 
  int i;
  const double EPS=std::numeric_limits<double>::epsilon();
  const double FPMIN=std::numeric_limits<double>::min()/EPS;
  double an,b,c,d,del,h,gln=gammln(a),rv;

  // assert(x>=(a+1));
  BOINCASSERT(x>=(a+1));
  b=x+1.0-a;
  c=1.0f/FPMIN;
  d=1.0/b;
  h=d;
  for (i=1;i<=ITMAX;i++) {
    an = -i*(i-a);
    b += 2.0;
    d=an*d+b;
    if (fabs(d)<FPMIN) d=FPMIN;
    c=b+an/c;
    if (fabs(c)<FPMIN) c=FPMIN;
    d=1.0/d;
    del=d*c;
    h*=del;
    if (fabs(del-1.0)<EPS) break;
  }
  // assert(i<ITMAX);
  BOINCASSERT(i<ITMAX);
  rv=(float)(log(h)-x+a*log(x)-gln);
#ifdef USE_MANUAL_CALLSTACK
  call_stack.exit();
#endif 
  return rv;
}

from stock codebase.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931002 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931004 - Posted: 20 Apr 2018, 7:41:20 UTC

BTW, looking at arm_neon.h from VS it seems __n128 plays same role there as __m128 for x86.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931004 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931110 - Posted: 20 Apr 2018, 23:58:01 UTC
Last modified: 20 Apr 2018, 23:58:24 UTC

Well, ARM path for opt codebase isn't complete
#ifdef __ARM_NEON
  v_armv7_ChirpData(
  sah_complex* cx_DataArray,
  sah_complex* cx_ChirpDataArray,
  int chirp_rate_ind,
  double chirp_rate,
  int  ul_NumDataPoints,
  double sample_rate
) {
; //TODO: neon port of SSE chirping
}
#endif

so SSE emulation would be preferable way to go indeed (especially because goal is to build OpenCL part, not just to get faster CPU build).
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931110 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931121 - Posted: 21 Apr 2018, 0:24:39 UTC - in response to Message 1931110.  

looks like (example https://github.com/nemequ/LZSSE-SIMDe/blob/master/lzsse8/lzsse8.cpp ) to use SIMDe all intrinsics should be re-written by prefixing them.
So, either separate path needed or additional re-defining layer.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931121 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931233 - Posted: 21 Apr 2018, 13:41:45 UTC
Last modified: 21 Apr 2018, 14:20:45 UTC

I'm going to commit initial SIMDe emulation of SSE on ARM.

But you need to modify configure line (lets omit -DUSE_OPENCL for now, need to deal with CPU code first): add -DUSE_ARMV7 to properly highlight build path. In this path it will attempt toreplace already written SSE code with its emulation via SIMDe.
Laso check if SIMDE_SSE_NEON and similar defines enabled in build path - this will allow to use NEON where possible instead of plain SIMD emulation.
Seems SIMDe able to deal with emulation even w/o NEON support but resulting code could be inacceptable slow.

Would be good if you attempt to build from new rev and write new errors you get. Emulation far from completion currently but would be good to know if it's right path to go or completely wrong one.

EDIT: also add -DUSE_JSPF and -DUSE_I386_OPTIMIZATIONS and -DUSE_I386_XEON

The goal is to select same path I know to be working one and emulate all SSE usage on it via SIMDe.

EDIT2: At revision: 3750
Now awaiting results of your attempt.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931233 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1931449 - Posted: 22 Apr 2018, 23:10:39 UTC
Last modified: 22 Apr 2018, 23:18:25 UTC

Well, I attempted to use Parallella device to build ARM version from opt codebase and failed much early...

parallella@parallella:~/sah_v7_opt/AKv8$ make
make -s all-recursive
Making all in client
In file included from /usr/include/c++/4.9/algorithm:60:0,
from /home/parallella/boinc/lib/std_fixes.h:54,
from ./../sah_config.h:672,
from <command-line>:0:
/usr/include/c++/4.9/utility:68:28: fatal error: bits/c++config.h: No such file or directory
#include <bits/c++config.h>
^
compilation terminated.
Makefile:1279: recipe for target 'seti_boinc-main.o' failed
make[2]: *** [seti_boinc-main.o] Error 1
Makefile:512: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:437: recipe for target 'all' failed
make: *** [all] Error 2

Seems it's some misconfiguration cause happened outside of out code....

Fast hack by copying sah_config from stock to opt codebase did not help:

parallella@parallella:~/sah_v7_opt/AKv8$ make
make -s all-recursive
Making all in client
In file included from main.cpp:53:0:
/usr/include/c++/4.9/cstdio:41:28: fatal error: bits/c++config.h: No such file or directory
#include <bits/c++config.h>
^
compilation terminated.
Makefile:1279: recipe for target 'seti_boinc-main.o' failed
make[2]: *** [seti_boinc-main.o] Error 1
Makefile:512: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:437: recipe for target 'all' failed
make: *** [all] Error 2

Seems that missing header included anyway....
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1931449 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : Building on Arm Linux


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.