Linux: v7 CUDA?

Message boards : Number crunching : Linux: v7 CUDA?
Message board moderation

To post messages, you must log in.

1 · 2 · Next

AuthorMessage
Profile Justin La Sotten
Avatar

Send message
Joined: 26 Jul 99
Posts: 11
Credit: 29,855,985
RAC: 0
United States
Message 1379957 - Posted: 11 Jun 2013, 18:33:20 UTC

It's rather hard to weed through these posts trying to find information regarding Linux.

I see that there are no stock applications for v7 + CUDA for Linux i386/x86_64. Is this planned?
I used to get a version (Lunatics?) from the KWSN site, but obviously there isn't a new one just yet.

While trolling these forums, I also stumbled onto a post that said something about using the old x41g-cuda app from Lunatics because it works with the v7 WUs. Is this true too?

For the time being, I've disabled the Anonymous Platform stuff, and am using the stock apps (I wasn't getting v7 to work at all). And while this is good, I'd like to get back to processing WUs on my 2 GPUs.

Thanks in advance for any help/advice/critisims/hate!
ID: 1379957 · Report as offensive
Mike Davis
Volunteer tester

Send message
Joined: 17 May 99
Posts: 240
Credit: 5,402,361
RAC: 0
Isle of Man
Message 1379961 - Posted: 11 Jun 2013, 18:36:42 UTC - in response to Message 1379957.  

There are some people working on a Linux gpu v7 app at the minute. There was a thread around a couple of days ago about it
ID: 1379961 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
Bulgaria
Message 1379965 - Posted: 11 Jun 2013, 18:42:49 UTC - in response to Message 1379957.  


Discussed in 'Porting s@h V7 to Linux':
http://setiathome.berkeley.edu/forum_thread.php?id=71818


 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 
ID: 1379965 · Report as offensive
Profile ivan
Volunteer tester
Avatar

Send message
Joined: 5 Mar 01
Posts: 783
Credit: 348,560,338
RAC: 223
United Kingdom
Message 1380068 - Posted: 11 Jun 2013, 23:43:43 UTC - in response to Message 1379965.  


Discussed in 'Porting s@h V7 to Linux':
http://setiathome.berkeley.edu/forum_thread.php?id=71818


And unfortunately as far as I'm concerned, real work is intruding on my efforts. My direct port works well as a standalone, and produces results as close to the CPU executable as you could expect. But it produces access violations when run from BOINC. JG has had more success with his port but last I heard wasn't fully satisfied with it. We'll get there someday -- I keep threatening to retire to get more time for this sort of thing but there are small problems like the lack of enough pension fund...
ID: 1380068 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1380080 - Posted: 12 Jun 2013, 0:25:46 UTC - in response to Message 1380068.  
Last modified: 12 Jun 2013, 1:01:52 UTC


Discussed in 'Porting s@h V7 to Linux':
http://setiathome.berkeley.edu/forum_thread.php?id=71818


And unfortunately as far as I'm concerned, real work is intruding on my efforts. My direct port works well as a standalone, and produces results as close to the CPU executable as you could expect. But it produces access violations when run from BOINC. JG has had more success with his port but last I heard wasn't fully satisfied with it. We'll get there someday -- I keep threatening to retire to get more time for this sort of thing but there are small problems like the lack of enough pension fund...


My status is that I have a sortof working well app for 64 bit later kernels only (lots of dependencies etc) but that there are issues with later Boinc showing up. 64 bit Cuda is of course non-ideal unless you require massive amounts of VRAM (which we don't)

In an ongoing effort I've managed to get an older Fedora 13 distro up and running (listed for Cuda 3.2 toolkit), though am experiencing issues with the flaky GTX260 I have in that machine (freezing X), and naturally a different set of issues building against older boincapi ;)

I expect to change the card in that machine once the test live run with x86_64, Cuda 5 on Ubuntu 12.04 LTS is completed (currently NNT is set). Despite the flakiness of the card, it looks like once proper error handling & threadsafe exits were enabled like on Windows, reliability of reported results has been great.

http://setiathome.berkeley.edu/show_host_detail.php?hostid=6439256
At the time of this post, errors stopped on the 7th when I enabled error handling & threadsafe exits. Plenty of valids, a couple of inconclusive that are probably this card's fault.

It would help out if by the time I get things sorted for an x86 build with less dependencies, interested parties were signed up at Crunchers Anonymous, ready for some controlled tests (alpha, debug & beta).

Jason
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1380080 · Report as offensive
Wedge009
Volunteer tester
Avatar

Send message
Joined: 3 Apr 99
Posts: 451
Credit: 431,396,357
RAC: 553
Australia
Message 1380213 - Posted: 12 Jun 2013, 9:42:37 UTC - in response to Message 1380080.  

64 bit Cuda is of course non-ideal unless you require massive amounts of VRAM (which we don't)

We never did have a stable Linux 32 build for the MB CUDA application, did we? As I recall, only a 64-bit version was available. I'm presuming there were issues that couldn't be resolved for 32-bit at that time.

Soli Deo Gloria
ID: 1380213 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1380233 - Posted: 12 Jun 2013, 11:45:13 UTC - in response to Message 1380213.  
Last modified: 12 Jun 2013, 11:45:27 UTC

64 bit Cuda is of course non-ideal unless you require massive amounts of VRAM (which we don't)

We never did have a stable Linux 32 build for the MB CUDA application, did we? As I recall, only a 64-bit version was available. I'm presuming there were issues that couldn't be resolved for 32-bit at that time.

That was most likely a function of available dev resources at the time. trying to build 32 bit with wide compatibility on x86_64 without fully functional autotools setup & multiple compilers / libraries available is awkward at best. So, I've gone the simpler route of installing an older 32 bit distro. The only problems I've encountered there so far are boincapi and equipment failure related. AFAICT the app code builds perfectly. Once the logistical issues are sorted out I expect it'll be no more challenging than the x64 build was.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1380233 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1383474 - Posted: 21 Jun 2013, 20:27:34 UTC

And slowly coming back around to get this operational, after having dealt with a number of other V7 teethng issues, namely some strange V7 Gaussian processing anomalies, and poking at the VLAR pulsefinding issue some more with test pieces (another story).

Status on my end is still getting my old fedora Cuda 3.2 setup going, having switched to a card that isn't dying it no longer locks up X, which is great. The 9600GSO is a bit too slow & RAM constrained, so I'll probably dig out the 480 to accelerate testing after successful build, and initial test on the slow card. It (9600GSO) has been running the rough x86-64 build on later Ubuntu for some time without any fault apparent, so should be good for proving an x86 more refined build soon.

Next step here then is finding a more workable boincapi, and sussing out all the required autotools changes needed to fix& update the build system, going full static etc. Not as fast an effort as I would have liked, but sometimes Life & V7 seem to take precedence lately.

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1383474 · Report as offensive
vanl

Send message
Joined: 18 Oct 00
Posts: 3
Credit: 18,397,801
RAC: 0
United States
Message 1383514 - Posted: 21 Jun 2013, 22:37:48 UTC

I've got MB for Linux CUDA running on my old Slackware system.
Once I ran out of V6 WUs I figured it was time to upgrade BOINC too.
Couldn't find a newer BOINC that worked with my libraries, so compiled my own. (7.0.65)
(It's not perfect, it pops up to the top on mouse over when it shouldn't.)

Decided to download/compile the seti Xbranch (mentioned in the other thread)
so installed nvidia toolkit from cuda_5.0.35_linux_64_sles11sp1-1.run.

A couple of changes to comment out boinc_fpops_cumulative() and change CFLAGS in the configure file produced a 64bit executable (setiathome_x41_x86_64-pc-linux-gnu_cuda50) that gave Q of 99.19% or better against CPU ref. app.
(setiathome_7.01_x86_64-pc-linux-gnu) using the KWSN Linux FG benchmark WUs (figured that was pretty good, though was hoping for better).

Created a app_info.xml for cuda50 and fired up BOINC, ran for a couple of days and added in CPU to app_info.xml. So far so good.

64 bit, but better than nothing,
Martin

http://setiathome.berkeley.edu/show_host_detail.php?hostid=5897238

mhvl@speedy:/nbu/mhvl/MBv7-Bench/KWSN-Bench-Linux-MBv7_v2.01.08.bkup/APPS$ ldd setiathome_x41_x86_64-pc-linux-gnu_cuda50
linux-vdso.so.1 => (0x00007fff119ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f57ad00b000)
libcudart.so.5.0 => /usr/local/cuda/lib64/libcudart.so.5.0 (0x00007f57acdaf000)
libcufft.so.5.0 => /usr/local/cuda/lib64/libcufft.so.5.0 (0x00007f57aadd2000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f57aaac3000)
libm.so.6 => /lib64/libm.so.6 (0x00007f57aa840000)
libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f57aa62a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f57aa2b3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f57ad228000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f57aa0af000)
librt.so.1 => /lib64/librt.so.1 (0x00007f57a9ea7000)

mhvl@speedy:/nbu/mhvl/BOINC.7.0.65/projects/setiathome.berkeley.edu$ cat app_info.xml
<app_info>
<app>
<name>setiathome_v7</name>
</app>
<file_info>
<name>setiathome_7.01_x86_64-pc-linux-gnu</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_v7</app_name>
<version_num>700</version_num>
<avg_ncpus>1.1</avg_ncpus>
<max_ncpus>7.0</max_ncpus>
<file_ref>
<file_name>setiathome_7.01_x86_64-pc-linux-gnu</file_name>
<main_program/>
</file_ref>
</app_version>
<app>
<name>setiathome_v7</name>
</app>
<file_info>
<name>setiathome_x41_x86_64-pc-linux-gnu_cuda50</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_v7</app_name>
<version_num>700</version_num>
<avg_ncpus>0.3</avg_ncpus>
<max_ncpus>0.3</max_ncpus>
<platform>x86_64-pc-linux-gnu</platform>
<plan_class>cuda50</plan_class>
<cmdline></cmdline>
<coproc>
<type>CUDA</type>
<count>0.49</count>
</coproc>
<file_ref>
<file_name>setiathome_x41_x86_64-pc-linux-gnu_cuda50</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>
ID: 1383514 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1383550 - Posted: 22 Jun 2013, 2:53:10 UTC - in response to Message 1383514.  


64 bit, but better than nothing,
Martin


Yep, Was a similar straightforward situation with 12.04LTS & Cuda5 here. Now it's to getting those dependencies down, and enabling the improved error/exit handling (some boincapi patching needed there). With a bit of luck I won't run into more issues hardware-wise, so fullsteam ahead to figure out updating the _autoetup business.
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1383550 · Report as offensive
Profile ivan
Volunteer tester
Avatar

Send message
Joined: 5 Mar 01
Posts: 783
Credit: 348,560,338
RAC: 223
United Kingdom
Message 1383662 - Posted: 22 Jun 2013, 13:57:20 UTC - in response to Message 1383514.  

I've got MB for Linux CUDA running on my old Slackware system.
Once I ran out of V6 WUs I figured it was time to upgrade BOINC too.
Couldn't find a newer BOINC that worked with my libraries, so compiled my own. (7.0.65)
(It's not perfect, it pops up to the top on mouse over when it shouldn't.)

Decided to download/compile the seti Xbranch (mentioned in the other thread)
so installed nvidia toolkit from cuda_5.0.35_linux_64_sles11sp1-1.run.

A couple of changes to comment out boinc_fpops_cumulative() and change CFLAGS in the configure file produced a 64bit executable (setiathome_x41_x86_64-pc-linux-gnu_cuda50) that gave Q of 99.19% or better against CPU ref. app.
(setiathome_7.01_x86_64-pc-linux-gnu) using the KWSN Linux FG benchmark WUs (figured that was pretty good, though was hoping for better).

Created a app_info.xml for cuda50 and fired up BOINC, ran for a couple of days and added in CPU to app_info.xml. So far so good.

Martin;
Could you please send me the diffs between your working source and the Xbranch? My compile worked straight out-of-the-box -- standalone. Any attempt to run under BOINC results in an error 11 (access violation, I believe).

Thanks,
ivan

ID: 1383662 · Report as offensive
vanl

Send message
Joined: 18 Oct 00
Posts: 3
Credit: 18,397,801
RAC: 0
United States
Message 1383913 - Posted: 23 Jun 2013, 13:10:49 UTC

Hi,

Patch below. It may be simpler to edit the changes into the cpp files.

Also my notes for building sah v7 Xbranch.

Martin


mhvl@speedy:/nbu/mhvl/seti/seti_svn/sah_v7_opt$ cat README.bld

svn checkout https://setisvn.ssl.berkeley.edu/svn/branches/sah_v7_opt

cd sah_v7_opt/Xbranch

#execute _autosetup

#in configure changed:
#MHVL CFLAGS="-march=x86_64 -msse3 -mfpmath=sse ${CFLAGS}"
CFLAGS="-march=native -msse3 -mfpmath=sse ${CFLAGS}"

#in client/analyzeFuncs.cpp and worker.cpp comment out boinc_fpops_cumulative()

./client/analyzeFuncs.cpp://MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
./client/worker.cpp://MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
./client/worker.cpp://MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);

./configure -enable-sse3 BOINCDIR=/nbu/mhvl/BOINC.7.0.65/boinc_repo CFLAGS='-I/opt/cuda-5.0/include'
make



--- ./client/worker.cpp 2013-06-23 07:56:24.013384331 -0500
+++ ../../../Xbranch/./client/worker.cpp 2013-06-11 05:05:12.020674848 -0500
@@ -172,7 +172,7 @@
retval = seti_do_work();
if (retval) SETIERROR(retval,"from seti_do_work() in worker()");

- boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
+//MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
#if defined(_WIN32)
fprintf(stderr,"Worker preemptively acknowledging a normal exit.->\n");
worker_thread_exit_ack = true;
@@ -188,7 +188,7 @@
remaining=0;
boinc_fraction_done(progress);
checkpoint(true); // force a checkpoint
- boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
+//MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
#if defined(_WIN32)
fprintf(stderr,"Worker preemptively acknowledging an overflow exit.->\n");
worker_thread_exit_ack = true;
--- ./client/analyzeFuncs.cpp 2013-06-23 07:56:24.025384330 -0500
+++ ../../../Xbranch/./client/analyzeFuncs.cpp 2013-06-11 05:04:08.138674805 -0500
@@ -892,7 +892,7 @@
fftlen = ChirpFftPairs[icfft].FftLen;
chirprate = (float)ChirpFftPairs[icfft].ChirpRate;
chirprateind = ChirpFftPairs[icfft].ChirpRateInd;
- boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
+//MHVL boinc_fpops_cumulative((SETUP_FLOPS+analysis_state.FLOP_counter)*LOAD_STORE_ADJUSTMENT);
// boinc_worker_timer();
#ifdef DEBUG
double ptime=static_cast<double>((unsigned)clock())/CLOCKS_PER_SEC+


ID: 1383913 · Report as offensive
Profile ivan
Volunteer tester
Avatar

Send message
Joined: 5 Mar 01
Posts: 783
Credit: 348,560,338
RAC: 223
United Kingdom
Message 1384868 - Posted: 26 Jun 2013, 16:15:54 UTC - in response to Message 1383913.  
Last modified: 26 Jun 2013, 16:39:26 UTC

Hmm, did all that and the first two are now running under BOINC rather than segfaulting immediately.
[Edit: And the third one home found a partner to validate against.]

Thanks.
ID: 1384868 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1385203 - Posted: 27 Jun 2013, 20:11:02 UTC - in response to Message 1384868.  

Alright, slowly getting a handle on what needs fixing for the autotools setup/configure as well.

Looks like for a generically applicable build I'll need to fix the NVCC compile options quite a lot, as the full -gencode strings aren't present. The specified arch settings will embed some binaries, though startup & performance would be sub-standard depending on card.

Along with those tweaks, I'll add (optional) minor boincapi tweaks, with patch & notes likely from 7.0.65 tag, to enable some of the improved thread-safety and exit handling functionality. Not a big deal on a pure crunching setup with very stable card, but very handy on failing cards (like my 260, set aside for now) or systems under pressure.


"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1385203 · Report as offensive
Profile petri33
Volunteer tester

Send message
Joined: 6 Jun 02
Posts: 1668
Credit: 623,086,772
RAC: 156
Finland
Message 1385236 - Posted: 27 Jun 2013, 22:18:14 UTC

Thank You guys for keeping up the good work!
I'm waiting for the output of Your efforts.

Whining (on):
--
I'm still running fedora 14 and ap_6.01r546_avx from lunatics and SAH x41g-CUDA from lunatics. The x41g cuda works fine with Seti v7 using a tweaked app_info.xml.

I tried compiling the source (boinc and seti) and managed to get them to compile, but with 4 children I have no time to test it. My guess is that it would have crashed. Tha hardest thing was linking the bunch together: I got numerous GLIBC-2.14 memcpy/strcpy or something like that errors.

What i'd really like is AVX + cuda versions of both MB and AP for linux.

Since I'm runnig fedora 14 I can't install boinc v7 and can't receive the 'normal' versions for my rig.
--
Whining (off):

I know - I have to update the linux version.

--

p.s.

Tried NVIDIA 3.19.xx version of the NVIDIA linux-64 driver.
+ Seti graphics was recognised and started automatically with my NV card(s). At least after log on I could see one of them running.
- (It) Started only with one card out of two. The second card did no processing at all. SAH recognised both of them (checked log) but only one was used (temp, time-to-completion increased).

--> reverted back to 3.10.51. Now I have to do "./boinc_client restart" after log on - otherwise cuda work will not start. .. but both cards do work after a manual restart.

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones
ID: 1385236 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
Bulgaria
Message 1385263 - Posted: 28 Jun 2013, 0:52:28 UTC - in response to Message 1385236.  

I have to do "./boinc_client restart" after log on - otherwise cuda work will not start. .. but both cards do work after a manual restart.

Find a way to delay boinc_client start (e.g. for 1-2 minutes) so the NVIDIA driver can start/load fully before BOINC attempt to detect presence of CUDA
(I don't know how to do that on Linux)


Since you have different GPUs:
Device 1: GeForce GTX 560 Ti, 1279 MiB
Device 2: GeForce GTX 660, 2047 MiB

... do you use:
<use_all_gpus>1</use_all_gpus>

http://boinc.berkeley.edu/wiki/Client_configuration#Options


 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 
ID: 1385263 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 5 Jul 99
Posts: 4654
Credit: 47,537,079
RAC: 4
United Kingdom
Message 1385285 - Posted: 28 Jun 2013, 4:35:12 UTC - in response to Message 1385263.  

I have to do "./boinc_client restart" after log on - otherwise cuda work will not start. .. but both cards do work after a manual restart.

Find a way to delay boinc_client start (e.g. for 1-2 minutes) so the NVIDIA driver can start/load fully before BOINC attempt to detect presence of CUDA
(I don't know how to do that on Linux)

How to delay start Boinc is posted here:

Debian/Ubuntu/Mint/Derivatives - GPU recognition fixes

Claggy
ID: 1385285 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1385306 - Posted: 28 Jun 2013, 6:06:49 UTC - in response to Message 1385236.  
Last modified: 28 Jun 2013, 6:10:37 UTC

...
--
I'm still running fedora 14 and ap_6.01r546_avx from lunatics and SAH x41g-CUDA from lunatics. The x41g cuda works fine with Seti v7 using a tweaked app_info.xml.

I tried compiling the source (boinc and seti) and managed to get them to compile, but with 4 children I have no time to test it. My guess is that it would have crashed. Tha hardest thing was linking the bunch together: I got numerous GLIBC-2.14 memcpy/strcpy or something like that errors.
...
Since I'm runnig fedora 14 I can't install boinc v7 and can't receive the 'normal' versions for my rig...


can you can stay on Fedora 14 for testing purposes ? I'm currently building/tweaking fine on FC13. Just trying to do a 'proper job' as opposed to my first hack attempts. Those hacks work but are not generalised enough, and don't include the robustness of the Windows apps yet. That means I'm digging into & fixing the _autosetup/configure/Makefile templates (which is taking time).
"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1385306 · Report as offensive
Bernd Noessler

Send message
Joined: 15 Nov 09
Posts: 99
Credit: 52,635,434
RAC: 0
Germany
Message 1385309 - Posted: 28 Jun 2013, 6:19:52 UTC - in response to Message 1385236.  


Now I have to do "./boinc_client restart" after log on - otherwise cuda work will not start. .. but both cards do work after a manual restart.


The reason for this is the way boinc works.
The nvidia driver is functional after the system has booted, it is part of the kernel.
But boinc expects some device nodes to exist before it can use the GPU.
These are normally created when the X-server is started the 1st time.

If you like to start boinc from a system startup script you have to create the device nodes by "hand".
For the first GPU add the following lines to your script:

mknod -m 666 /dev/nvidia0 c 195 0
mknod -m 666 /dev/nvidiactl c 195 255


This way you also can run boinc on systems without an X-server.
ID: 1385309 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1385381 - Posted: 28 Jun 2013, 13:33:03 UTC
Last modified: 28 Jun 2013, 14:00:57 UTC

Just a heads up that I've done the first part of updates to the build system,

sh ./_autosetup
sh ./configure --enable-sse2 --enable-fast-math BOINCDIR=/your_boinc_repo/
make

(or equivalents) should be enough to get a 'working' build in most circumstances now, though still some work to do with making more libs static, and then enabling more robust error handling.

Any questions about these updates & what remains, feel free to ask.

"Multibeam V7 Cuda, Linux Build system prelim updates: nvcc.m4 - disable with-cuda option( updated to full nvcc -gencode strings instead of arch spec. base Cuda version required 3.2 (for now). cuda include directory added to CFLAGs. match nvcc bitlevel to host compiler target. Makefile.incl - Added ORIGIN rpath to LDFLAGS, to enable locating the libraries in executable's directory, tweaked output name. client/Makefile.am - remove deprecated preprocessor definition & kernel file target

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.
ID: 1385381 · Report as offensive
1 · 2 · Next

Message boards : Number crunching : Linux: v7 CUDA?


 
©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.