The 3.2.0 version of Genefer (Version 3.00 on BOINC) requires a minimum CUDA version of 5.5. I *think*, but am not certain, that this corresponds to driver version 320.

The app won't run with an earlier version of CUDA and will give you an error about having an insufficient driver level.

The server is configured to not send you GFN CUDA tasks unless your system has driver that supports CUDA 5.5.

If you're not getting GFN tasks, try upgrading your driver.


____________
My lucky number is 75898⁵²⁴²⁸⁸+1

This may be a short lived problem. I'm testing the next version of the Genefer apps, which are significantly faster. The new OpenCL app runs about 20% faster than the CUDA app, so we may just eliminate the CUDA app completely.

That speed comparison is on a GTX 580, which was faster on CUDA than OpenCL in the past.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

This may be a short lived problem. I'm testing the next version of the Genefer apps, which are significantly faster. The new OpenCL app runs about 20% faster than the CUDA app, so we may just eliminate the CUDA app completely.

That speed comparison is on a GTX 580, which was faster on CUDA than OpenCL in the past.

This may be a short lived problem. I'm testing the next version of the Genefer apps, which are significantly faster. The new OpenCL app runs about 20% faster than the CUDA app, so we may just eliminate the CUDA app completely.

That speed comparison is on a GTX 580, which was faster on CUDA than OpenCL in the past.

The CUDA vs. OpenCL tests need to be done on a broader array of GPUs than a GTX580. The OCL vs. CUDA differences on different GTX 4xx and 5xx cards were quite variable in the past.

Is this the same new apps as were just released in PRPnet? If so, I'll test on a couple of card versions over the next couple of days to add to the testing.

This may be a short lived problem. I'm testing the next version of the Genefer apps, which are significantly faster. The new OpenCL app runs about 20% faster than the CUDA app, so we may just eliminate the CUDA app completely.

That speed comparison is on a GTX 580, which was faster on CUDA than OpenCL in the past.

The CUDA vs. OpenCL tests need to be done on a broader array of GPUs than a GTX580. The OCL vs. CUDA differences on different GTX 4xx and 5xx cards were quite variable in the past.

Is this the same new apps as were just released in PRPnet? If so, I'll test on a couple of card versions over the next couple of days to add to the testing.

I have a gtx770 with 2600K running linux ubuntu 14.04. Just yesterday updated the o/s (from 13.10). After that, with the old video driver (304.xx) and the new PG app, gfn OCL tasks failed immediately (but did download, then fail), and GFN CUDA didn't download at all. Not surprising given the info above... crashed a lot of pps sieve tasks too; sorry about that.

Updated the latest nvidia driver today from the nvidia website. The linux repositories that I subscribe to don't seem to have anything more recent than a 304.xx driver. I grabbed NVIDIA-Linux-x86_64-331.79.run from their site and installed it as follows:
stop window manager with ctrl-alt-f1
stop X with (as root, or with sudo) "sudo service lightdm stop"
cd to wherever you save the above .run file, and run it with "sudo sh ./NVIDIA..."
There are then several windows requiring responses; just keep responding "yes", "go ahead", "i agree", or whatever. Use the keyboard arrow keys to select the proper response.
After the installer was complete, I rebooted. Then held my breath. Or one could just get back into the window manager with "sudo service lightdm start".

It booted into the GUI. Yay.

I first tried a few pps sieve units. Remember, I'd just done an o/s upgrade, a video driver upgrade, and have new PG apps downloaded, one right after the other. Those WUs seemed to work; speed looks about the same as before. Now I'm running GFN CUDA (short). The WU I have appears to be working, but it will be several hours before it finishes, and I hesitate to declare victory before it validates. Next, I will try GFN-OpenCL to see how that works with the new setup.

CUDA version reported (in the boinc log) with the above driver version is 6.0.

Why can't computers be as easy to use as a toaster? Sorry, rhetorical question.

--Gary

Gary,

Glad to hear CUDA is working for you.

You might want to try the OpenCL version, for three reasons:

1) It's faster on your GPU, and the next OpenCL version will be even faster.

2) There's a good chance when the next OpenCL app goes live, we'll be turning off the CUDA app because it's looking like the OpenCL app will be faster no matter what GPU you have. You'll want to know if the OpenCL app works -- and so do we.

3) Earlier today I discovered a problem with the Windows OpenCL app. I want to know if it also affects the Linux OpenCL app so we can also fix that app, if needed. The Windows OpenCL app, when running under BOINC, hogs an entire CPU core. It's supposed to use a full core if the CPU is idle, but if all the cores are busy it should only use a fraction of a core. That worked under PRPNet, but not under BOINC. We've fixed it for the next Windows OpenCL version, but we need to know if this also affects Linux and Mac.

____________
My lucky number is 75898⁵²⁴²⁸⁸+1

GFN 3.00 Ubuntu CUDA unit finished and validated (ID 395052353). Dang I was about a half hour late, though the wingman had a big head start :-)

OpenCL unit with Ubuntu GFN 3.00 (id 395195414) is running now. Yes, it started up OK and appears healthy. Same environment as the above, except for OpenCL vs. CUDA. Faster? Yes, somewhat. The CUDA WU I just finished took 10.4+ hours. If I extrapolate the progress on the current OpenCL unit (still early on), it looks like right at 10 hours.

As for processor usage, if I set boinc at 50 or 75 % of available processors (2600K, 4 physical cores, HT off) the OpenCL app does indeed use ~100% of a core, over and above the 2 or 3 cores of what LLR is using. If I load the CPU with a full 4 LLR tasks, the GFN OpenCL app *still* runs at 100% (-ish) of a core, forcing two of the LLR's to split a core 50/50. Running LLR on either 3 or 4 cores, plus GFN OpenCL, makes the CPU run *really* hot, so much that I need to run just 2 LLR's (yes, I could use better cooling). The GFN CUDA app that I ran first used maybe 11 or 12% of a core on average (which is in line with the behavior of the old app, and prior to the o/s update). Temps were OK with 3 LLR's also running in that case.

--Gary

OpenCL unit with Ubuntu GFN 3.00 (id 395195414) is running now. Yes, it started up OK and appears healthy. Same environment as the above, except for OpenCL vs. CUDA. Faster? Yes, somewhat. The CUDA WU I just finished took 10.4+ hours. If I extrapolate the progress on the current OpenCL unit (still early on), it looks like right at 10 hours.

As for processor usage, if I set boinc at 50 or 75 % of available processors (2600K, 4 physical cores, HT off) the OpenCL app does indeed use ~100% of a core, over and above the 2 or 3 cores of what LLR is using. If I load the CPU with a full 4 LLR tasks, the GFN OpenCL app *still* runs at 100% (-ish) of a core, forcing two of the LLR's to split a core 50/50.

Doing testing on PRPnet GFN524288 port with a pair of GTX 460s. Results look good.

GeneferCUDA results range from 5 hours to 5 hours 15 minutes each.

New OCL version results range from 4 hours 11 minutes to 4 hours 48 minutes.

That is between 5% to 20% faster. The longer time on OCL still had the CUDA version running on the other card (these are in the same box), so that might explain the widely different performance. I'll keep running with the new OCL version to see if these times stabilize nearer to the shorter time.

Will test on a GTS 450 and GTX 550 Ti when I get home today.

OpenCL GFN (short) 3.0 unit finished, hopefully successfully (and hopefully prime!... okay, that's a stretch...) a couple of hours ago. It *was* faster than the CUDA app, although not by much, maybe 5-10%. Compare the WU ID links I posted prior for specifics.

Yes, the "CPU hog" issue with OpenCL appears in linux too, it seems.

As for the original title of this thread, CUDA 6.0 works with the current app under linux, for sure. CUDA 5.0 does *not* work, everything else unchanged (no surprise there). I never had an install of 5.5 so I can't speak to that.

--Gary
p.s. PPS Sieve GPU is also working happily with the new configuration.
p.p.s. Sorry I can't help with Mac testing. I have Macs, but they are old, and the GPUs are not double precision.
p.p.p.s. @Rick: your gtx770 OpenCL gfn/short timings are right in line with mine.

Will test on a GTS 450 and GTX 550 Ti when I get home today.

Not really, the entire FFT algorithm used by geneferCUDA is buried inside the CuFFT library, so we can't easily touch it without re-implementing the whole thing by hand. Yves already did this in the OpenCL app, so we were able to modify it to use the (faster) z-Transform, rather than the DWT that is still used by the CUDA app.
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime!

Not really, the entire FFT algorithm used by geneferCUDA is buried inside the CuFFT library, so we can't easily touch it without re-implementing the whole thing by hand. Yves already did this in the OpenCL app, so we were able to modify it to use the (faster) z-Transform, rather than the DWT that is still used by the CUDA app.

Not really, the entire FFT algorithm used by geneferCUDA is buried inside the CuFFT library, so we can't easily touch it without re-implementing the whole thing by hand. Yves already did this in the OpenCL app, so we were able to modify it to use the (faster) z-Transform, rather than the DWT that is still used by the CUDA app.

I was also curious if any of the CUDA 6 improvements would be useful in a similar fashion?

With the latest release of Genefer 3.2.2 (released as BOINC apps 3.01), CUDA 6.0 is required for the Mac apps. Windows and Linux still use CUDA 5.5.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1