BRP6-opencl-ati with linux mesa opencl
13 Jan 2016 21:30:07 UTC
Topic 198372
(moderation:
I was just wondering if anyone had any luck with running BRP6-opencl-ati GPU tasks under linux using the MESA opencl (clover) implementation?
I've tried recently and the workunit exits immediately with error, see this task: https://einsteinathome.org/task/539957876
Any ideas what is going wrong? E.g. what those error codes mean? Is the opencl implementation simply missing some functionality?
I wanted to have a look at the source, however the link http://einstein.phys.uwm.edu/download/brp-src-release.zip is not working.
BRP6-opencl-ati with linux mesa opencl
)
Thanks for reporting this. It is available again.
Thanks for the fixed source
)
Thanks for the fixed source link, it was quite helpfull. I wasn't able to to actually build it since all my tries to clone the required repositories from http://gitmaster.atlas.aei.uni-hannover.de/ failed, however looking at the kernels it looks like the problem is that mesa clover opencl is missing the modf math builtin function.
I'll report a bug at freedesktop bugzilla.
After some troubles I was
)
After some troubles I was able to implement the modf opencl builtin in libclc and get it upstreamed.The Binary Radio Pulsar Search apps seems to run fine with my mobile AMD Radeon R5 M330 (with the mesa radeonsi driver). https://einsteinathome.org/task/542169739
It is quite slow, however that is probably expected from such a lowend notebook GPU. If someone has a similar GPU crunching using the windows or catalyst linux driver I would be interested in comparison.
Moreover there are still some troubles on the mesa side. I've tried a different card generation (AMD Radeon HD 8490) powered by the r600g driver and the results were completely wrong. I used the standalone test from this thread for testing http://einsteinathome.org/node/197052&nowrap=true#140694, since I still haven't managed to build the brp app from source. And there were some errors in the log "radeon: Not enough memory for command submission." So maybe with just 1GB of memory this card is simply not powerful enough? What are actually the memory requirements for the brp app?
Also if someone knows how to fix those build errors in the brp app, I would appreciate some pointers. It seems to me, that the stat.h header which comes with my glibc is mission some stuff, however I have no idea how to fix this:
g++ -g -mfpmath=sse -msse -I/home/ondracka/Stažené/brp-src-release2/install/include -I/home/ondracka/Stažené/brp-src-release2/install/include -I/home/ondracka/Sta\�\�en\�\�/brp-src-release2/install/include -I/home/ondracka/Stažené/brp-src-release2/install/include/libxml2 -I/home/ondracka/Stažené/brp-src-release2/install/include/boinc -I/usr/local/cuda/cuda/include -I/opt/AMDAPP/include -I../include -malign-double -DHAVE_INLINE -DBOINCIFIED -DUSE_OPENCL -DNDEBUG -DLOGLEVEL=info -rdynamic -O3 -Wall -ggdb3 -fprofile-use -c /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c: In function ‘off_t get_file_size(const char*)’: /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c:364:33: error: no matching function for call to ‘stat::stat(const char*&, stat*)’ if (stat(file_name, &statbuf) < 0) { ^ In file included from /usr/include/fcntl.h:77:0, from /home/ondracka/Stažené/brp-src-release2/install/include/sysdep.h:65, from /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c:25: /usr/include/bits/stat.h:46:8: note: candidate: stat::stat() struct stat ^ /usr/include/bits/stat.h:46:8: note: candidate expects 0 arguments, 2 provided /usr/include/bits/stat.h:46:8: note: candidate: stat::stat(const stat&) /usr/include/bits/stat.h:46:8: note: candidate expects 1 argument, 2 provided /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c:370:40: error: ‘S_ISREG’ was not declared in this scope } else if (!S_ISREG(statbuf.st_mode)) ^ /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c: In function ‘void bfd_fatal(const char*)’: /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c:330:1: warning: ‘noreturn’ function does return } ^ /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c: In function ‘void fatal(const char*, ...)’: /home/ondracka/Stažené/brp-src-release2/src/erp_execinfo_plus.c:345:1: warning: ‘noreturn’ function does return } ^ Makefile:121: návod pro cÃl „erp_execinfo_plus.o“ selhal make: *** [erp_execinfo_plus.o] Chyba 1 ************************************ Error detected! Stopping build! Po úno 1 09:22:51 CET 2016 ************************************Exactly my problem
)
Exactly my problem too!
https://einsteinathome.org/task/544025111
I take it no one else has figured this out? I'm using an development build of BOINC, but official Einstein@home apps. I ran Lunatics apps on anon platform for a long time, so, I'm willing to test code too if that's helpful.
Getting BOINC to recognize GPUs through MESA driver was a major revelation to me! So, I'd love to get any project that has support for it! It's too hard to even know if it will work before you join and try. So, if you know a project that has working apps, I'd be interested in that, too.
As I have mentioned, the
)
As I have mentioned, the patches to fix the "Couldn't build OpenCL program (error: -11)!" are now in the upstream libclc, so if you compile and install latest libclc from subversion (or github git mirror) it should be working.
I have a rpm with the fix for fedora, if you are interested, ping me with private message. For other distros I guess you will have to build the package by yourself or wait some time before it gets into the repositories via update.
Regarding the overal situation, it is a little bit unfortunate. Fedora is still stuck with quite ancient BOINC 7.2.42 (with no Mesa or Beingnet OpenCL detection). I guess there are some troubles on the boinc side with Linux support since 7.2.42 is also the latest recommended Linux version on BOINC site. I have managed to build the 7.6.22 version and I have noticed that the BOINC manager seems to freeze a lot with 100% CPU usage, however I did not look into it closely yet. Client seems to work fine though.
IMHO it would really help a lot of inexperienced users if the GPU detection and apps worked out of the box with stock packages from the distributions, since installing the proprietary drivers is huge pain and the Mesa drivers are usually better than Catalyst driver for normal desktop usage (web browsing, compositing, casual gaming, videos). However OpenCL performance seems to be still better in the Catalyst as well as performance in some games, at least according to Phoronix benchmarks.
RE: As I have mentioned,
)
Okay, thanks for clarifying. (I wasn't just piling on; I couldn't tell you had identified the root cause and the fix.)
Sounds perfect! Will do. I could build from SRPM too, that's fine too. I'm happy to file a bug or add myself to yours, especially if you have a patch ready.
That's an understatement; the situation is terrible. I didn't realize 7.2 was so old or that there had been any progress because there haven't been any official updates to the Linux release. But, I just built client 7.6.23 and was shocked that it detected my GPUs via MESA. Didn't bother with manager, though; BOINC says the problem with wxWidgets is why they haven't updated their releases package for Linux.
Agreed! And I wouldn't limit it to inexperienced users; it's valuable to most of the community. I remember how to build a kernel, but I'm not doing that anymore. I wouldn't be here if the proprietary drivers were even a little better maintained. But, at this point, I'll take the performance hit for all the stability and maintenance advantages of the OSS stack. I always ran proprietary drivers and I thought things were getting better when folks started repackaging them in RPM form. But, that stopped, and now you add high frequency kernel changes and the AMDGPU transition...it's a nightmare.
Awesome! It's working, I
)
Awesome! It's working, I think: it's run for 5 minutes, used to crash at 2 seconds. Thanks, Paulie!
I'll let it finish the work I have. If there aren't errors, I'll get more work.
I can compare peak RAC now with a few months ago, but it will have to build up a bit, first.
My completed tasks have
)
My completed tasks have already been validated. Awesome, I'm so pleased.
Thanks again, Paulie!
Paul, any chance you could
)
Paul, any chance you could unhide your computers or give a link to the one using Mesa? It would be interesting to compare runtimes with Mesa to other hosts running Catalyst. Elsewhere you said you have HD 7870 and I would expect those to be more common than Paulie's R5 M330.
While it is impressing that open source community has finally produced working OpenCL drivers for ATI (the first time I saw GPGPU stuff on some open source todo list was years ago) I'm not sure if the performance is equally impressing.
Paulie is running Parkes tasks on both Intel and ATI GPUs with runtimes of 55Ks on Intel and 46Ks on ATI. I thought that when laptop manufacturers add discrete GPUs the discrete GPU would be significantly faster than the integrated one. The 20% difference between ATI and Intel seems rather low to me.
RE: Paul, any chance you
)
He already did (effectively) in this earlier message. Here is a link to the full results list for the computer. There are lots of completed BRP4G and now there is also a BRP6 which has validated. The elapsed time was 6663 secs which does seem a little slow compared to the fglrx driver. I have a number of 7850s running 4x which complete 4 tasks in just over 5 hours - ~4600 secs per task.
It would be interesting to see what improvement he gets if he at least ran 2x. His host details page shows two coprocessors but that doesn't necessarily mean they are both the same. I looked at a number of stderr.txt outputs for completed BRP4G tasks and they ALL seem to show
Using OpenCL device "AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0)" by: AMDI thought it would show gpu 0 or gpu 1 (or something like that) if two different devices were involved.The reported memory on the host details page is 1024MB so he could run 2x and probably 3x if he wanted to. I don't know how the driver might react to that.
Cheers,
Gary.