SETI MB CUDA for Linux

[Jason G]

Edit: The old broken 32bit Linux Cuda app really should be removed from the first post.

Done:

[Mod:] Removed outdated build

Was 64bit  OK ? I can put that back if needed, or better yet, put it in a proepr place.

[Claggy]

Edit: The old broken 32bit Linux Cuda app really should be removed from the first post.

Done:

[Mod:] Removed outdated build

Was 64bit  OK ? I can put that back if needed, or better yet, put it in a proepr place.

64bit app was O.K, only 32bit app bad, see this post from a long while ago:

Any news on this?

Unfortunately no. All 32bit builds had the same error. If you can, run the 64bit app, else it's better not run CUDA for the time being.

Then I think somebody should add a warning to the original post or remove the 32bit app entirely.

Unfortunately I only have 32bit linux installed. The last time I tried 64bit I had a sound problem in some 32bit games, so I just reverted to 32bit. Perhaps I should give it a try again, but I don't think this will happen anytime soon.

Claggy

[Jason G]

OK, modding [Done]

[Mod:] Removed outdated/bad 32 bit build

[Metod, S56RKO]

If you read the first dozen pages of this thread, you'll see that the original 32bit Linux Cuda app was broken, it might be that the x86, 2.2, vlar-kill app isn't totally reliable eithier,
If you can, try swapping to a 64bit OS and use the 64bit app instead.

Ah, well, I kinda hoped that somebody would be nice enough to provide a good 32-bit Linux CUDA app. I can't really go to 64-bit on this machine. I actually had to go from 64-bit to 32-bit due to requirements on what this machine does for its living.

[glennaxl]

Anyone tried setiathome-CUDA_3.0_6.09.x86_64_vlarkill with cuda32?

It seems that all dependency get resolved when I tested it under VMware except for libcuda.so as cuda is not exposed under VMware.

Code: [Select]

ldd setiathome-CUDA_3.0_6.09.x86_64_vlarkill
        linux-vdso.so.1 =>  (0x00007ffff6fff000)
        libcufft.so.3 => /usr/local/cuda/lib64/libcufft.so.3 (0x00007fa18cf7d000)
        libcuda.so.1 => not found
        libcudart.so.3 => /usr/local/cuda/lib64/libcudart.so.3 (0x00007fa18cd2f000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa18ca29000)
        libm.so.6 => /lib/libm.so.6 (0x00007fa18c7a6000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa18c588000)
        libc.so.6 => /lib/libc.so.6 (0x00007fa18c205000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa18ed44000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fa18c001000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa18bdea000)
        librt.so.1 => /lib/librt.so.1 (0x00007fa18bbe2000)


[sunu]

Anyone tried setiathome-CUDA_3.0_6.09.x86_64_vlarkill with cuda32?

Supposedly setiathome-CUDA_3.0_6.09.x86_64_vlarkill was done for fermi compatibility but when I tested it, it wasn't working.

[Jason G]

Anyone tried setiathome-CUDA_3.0_6.09.x86_64_vlarkill with cuda32?

Supposedly setiathome-CUDA_3.0_6.09.x86_64_vlarkill was done for fermi compatibility but when I tested it, it wasn't working.

Not surprising given the Fermi incompatibilities inherited from 'old stock' Cuda code (all platforms) are fairly specific, complex, and not related directly to Cuda version (apart from needing at least Cuda 3 for fermi binaries)

FYI,
Have got a few other responsibilities sorted today, so should hopefully be able to get some Linux guys on the case soon.  No firm timetable yet, for Linux, but wheels are in motion.  Will try to provide more info as something more tangible develops.

Jason

[sunu]

Not surprising given the Fermi incompatibilities inherited from 'old stock' Cuda code (all platforms) are fairly specific, complex, and not related directly to Cuda version (apart from needing at least Cuda 3 for fermi binaries)

When I tested it, it produced garbage results in all WUs except VLAR ones. It could run VLAR workunits in fermi GPUs and produce valid results.

FYI,
Have got a few other responsibilities sorted today, so should hopefully be able to get some Linux guys on the case soon.  No firm timetable yet, for Linux, but wheels are in motion.  Will try to provide more info as something more tangible develops.

Nice to hear that

[Jason G]

When I tested it, it produced garbage results in all WUs except VLAR ones. It could run VLAR workunits in fermi GPUs and produce valid results.

LoL, that's kindof amusing but logical by nature of some of the issues. Thanks. That info will help track down & check any issues that might need resolving in an x32f port.  Fingers crossed it should be reasonably straightforward from here.  Once operational will likely be attempting to keep Linux builds up to date with Windows ones (My primary Platform) , so all going well shouldn't miss out on coming optimisations worked out in the Unit test threads.

Jason 

[riofl]

i just upgraded my nvidia driver to linux 64 version 260.19.29 and nvidia-settings of the
same version.

since this upgrade my 2nd video card will not release gpu core temps.

gpu0 is a gtx285
gpu1 and 2 is a dual processor gtx295

gpu0 still reads out fine in gkrellm properly but shows 0 for gpu1 and gpu2.

gkrellm is asking for the temps for all gpus according to the process list

when i run the command manually here is what i get:... the number 64 in the gpu0 readout
is the correct temp. the other 2 return a 0:


odyssey bin # nvidia-settings -q [gpu:0]/GPUCoreTemp
Xlib:  extension "RANDR" missing on display ":0".

  Attribute 'GPUCoreTemp' (odyssey:0[gpu:0]): 64.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.

odyssey bin # nvidia-settings -q [gpu:2]/GPUCoreTemp
Xlib:  extension "RANDR" missing on display ":0".

  Attribute 'GPUCoreTemp' (odyssey:0[gpu:2]): 0.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.

odyssey bin # nvidia-settings -q [gpu:1]/GPUCoreTemp
Xlib:  extension "RANDR" missing on display ":0".

  Attribute 'GPUCoreTemp' (odyssey:0[gpu:1]): 0.
    'GPUCoreTemp' is an integer attribute.
    'GPUCoreTemp' is a read-only attribute.
    'GPUCoreTemp' can use the following target types: X Screen, GPU.


is this a problem with the new driver?

i also recompiled cuda toolkit 2.3 to be sure everything was synchronized.

[sunu]

You'll need to query the thermal sensors directly:

nvidia-settings -q [thermalsensor:0]/ThermalSensorReading

Each card has two thermal sensors, core and ambient, so thermal sensors 0,2,4 will be the core temperatures and 1,3,5 will be the ambient temperatures.

[riofl]

cool that worked thanks!

what i cannot understand is why then does gpu0 still work under the old syntax?

i would think it would be all or nothing.

[sunu]

what i cannot understand is why then does gpu0 still work under the old syntax?

Probably because it has a x server running while the other gpus do not.

[riofl]

my x server *i think* uses 2 gpus cause i have 3 monitors hooked up, both vid cards are defined and used in xorg.conf and the screens are defined as the gpu0 card both ports are xinerama and then that screen is twinviewed into the 3rd one.

just weird..

i found a better utility to check gpu temps and bill put the call into his gkrellm so there is now a choice of using nvidia-settings gputemp or using nvidia-smi which works perfectly.. also gives a nicer formatted output if you just want to look manually..

nvidia-smi -q -a

[riofl]

is the fermi driver reliable on linux yet? i am thinking of replacing both my cards with a gtx 590