Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummers-lowrise
|
Message boards :
Generalized Fermat Prime Search :
Deprecating GeneferCUDA
Author |
Message |
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
We've now started formal testing of GeneferOCL 3.3.0. Once 3.3.0 is live, we plan on removing the GeneferCUDA apps.
As far as we know, in all situations, GeneferOCL is faster than GeneferCUDA. The only reason for using GeneferCUDA was that GeneferCUDA wouldn't use a full CPU core. GeneferOCL would use a full core, under some circumstances. Since GeneferOCL 3.3.0 has fixed the problem with CPU hogging, there appears to be no reason to use GeneferCUDA anymore.
If you have a reason why we should keep GeneferCUDA, now is the time to speak up. Once we turn it off, it will be too late.
____________
My lucky number is 75898524288+1 | |
|
|
Bought TWO r89 380x just for primegrid. Been trying to get the R9 380x to work with Primegrid and it wont. Asked for help on the forums for app_info and nothing. If you switch over to opencl, make it work with AMD.
____________
| |
|
|
Is there a SIMPLE way to install ocl? I need help with that.
Thanks | |
|
|
Which GPU's does this make unable to run PrimeGrid?
Currently my older laptops with series Quadro FX 1600m, FX 2800m and FX3700m can all run CUDA WU's with minimal CPU usage. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
Which GPU's does this make unable to run PrimeGrid?
Currently my older laptops with series Quadro FX 1600m, FX 2800m and FX3700m can all run CUDA WU's with minimal CPU usage.
Are they unable to run GeneferOCL?
____________
My lucky number is 75898524288+1 | |
|
|
When you move support R9 290/290X ???????
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
When you move support R9 290/290X ???????
As soon as we're able to.
Please see on-topic discussions about this in other threads such as this: http://www.primegrid.com/forum_thread.php?id=6667
Problems with ATI/AMD GPUs have nothing to do with whether or not GeneferCUDA goes away. Please keep this thread about GeneferCUDA.
Further off-topic posts in this thread will be removed.
____________
My lucky number is 75898524288+1 | |
|
|
An interesting point regarding the older cards.
I just fired up the first test 65536 unit using both cuda and ocl on a mac with a 320m, and it did fine under the test ocl executable and the production oclcuda executable, aside from being painfully slow. That gpu is compute capability 1.2, however. I have a quadro 5600 and an 1800fx sitting in a drawer, and they are cc 1.0, if my memory serves me correctly.
Would there be any value in testing against these, at least for the shorter tasks, or do cuda's b limits put it in a catch-22 (can't run the shorter tasks, and the longer ones are just too long to be practical)? | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
An interesting point regarding the older cards.
I just fired up the first test 65536 unit using both cuda and ocl on a mac with a 320m, and it did fine under the test ocl executable and the production oclcuda executable, aside from being painfully slow. That gpu is compute capability 1.2, however. I have a quadro 5600 and an 1800fx sitting in a drawer, and they are cc 1.0, if my memory serves me correctly.
Would there be any value in testing against these, at least for the shorter tasks, or do cuda's b limits put it in a catch-22 (can't run the shorter tasks, and the longer ones are just too long to be practical)?
CUDA is only usable on n=21 and n=22 tasks, which are incredibly long computations for old, slow cards. A top-of-the-line GTX 280 takes about 10 days to run an n=22 task. Even older cards will take a lot longer.
From my perspective, I want to get rid of the CUDA app for the following reasons:
1) On all hardware that I'm aware of, GeneferOCL is faster than GeneferCUDA.
2) The next version of GeneferOCL (3.3.0), currently in testing, fixes the "hogs a CPU core" problem, so that's no longer a reason to use GeneferCUDA.
3) Many people mistakenly use GeneferCUDA instead of GeneferOCL, which significantly reduces the performance of their GPUs.
4) There's no hardware I'm aware of that can run GeneferCUDA but can not run GeneferOCL.
It's possible that I'm mistaken about #1 or #4. That's the purpose of this thread. If you've got a GPU that currently can run GeneferCUDA but can't run GeneferOCL, or is slower with GeneferOCL, I want to know about it.
If there's a reason I haven't thought of for keeping GeneferCUDA, I want to hear about it.
____________
My lucky number is 75898524288+1 | |
|
RafaelVolunteer tester
 Send message
Joined: 22 Oct 14 Posts: 905 ID: 370496 Credit: 459,496,650 RAC: 148,364
                   
|
CUDA is only usable on n=21 and n=22 tasks, which are incredibly long computations for old, slow cards. A top-of-the-line GTX 280 takes about 10 days to run an n=22 task. Even older cards will take a lot longer.
And even then, you'd be better off doing manual sieve for n=21;22 rather than Genefer.
But anyway, one question. Would the CUDA app be deleted and not being able to be found anywhere else, or would we just remove it from the selection page, storing it "in an archive" or something?
Reason I'm asking is for the sake of newer hardware releases (Pascal comes to mind); while very unlikekly that it'll ever be a better option than OCL, it is possible that the new architectures contain a bug that makes OCL unable to run - such as the Skylake iGPU being unable to run OCL3 where previous Intel graphics can. Or OCL performance being not so great - such as AMD AVX for LLR. Or maybe CUDA just being plain faster - such as OCL3 being much better on Maxwell than anything else. | |
|
|
Would the CUDA app be deleted and not being able to be found anywhere else, or would we just remove it from the selection page, storing it "in an archive" or something?
Nothing is deleted, it's all stored in the SVN history. I might remove the CUDA code from the trunk in the next release, just to save on maintenance - CUDA is also the ugly-duckling transform that it not properly encapsulated.
It would be relatively easy to resurrect at another time, and old binaries would always be available.
- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime! | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
CUDA has not really been worked on since Yves came back and wrote the OCL apps. All improvements are only being performed on the OCL code; no changes are made to the CUDA code anymore.
It's unlikely -- bordering on impossible -- that CUDA would work better on any new architectures simply because OCL is the app that will be optimized for new architectures. Nobody's worked on CUDA for a few years now.
On Nvidia GPUs, the difference between CUDA and OCL is analogous to the difference between the "C" and "C++" languages. They both essentially do the same thing, in similar ways, but are somewhat different. (Ignore the object oriented stuff for the purposes of this analogy.) One isn't necessarily better than the other other, but they're different.
The reason GeneferOCL is faster than GeneferCUDA isn't because OCL is inherently faster on hardware X than is CUDA; it's because for the last two years Yves has been working hard at making Genefer faster, and he's working on GeneferOCL. GeneferCUDA is simply obsolete, and there seems to be no need anymore to maintain two different versions of what's essentially the same program. The last remaining reason for using GeneferCUDA (i.e., GeneferOCL hogging a CPU core) goes away with the 3.3.0 release of Genefer.
____________
My lucky number is 75898524288+1 | |
|
|
All of my recent Genefer workunits were described as using OCLcuda rather than only CUDA or only OCL. Should I consider them as showing that both of my computers should be able to run the 3.30 OCL version?
If not, how can I get a few 3.30 workunits for each of my computers to test how well they will handle 3.30?
Someone asked how to install ocl. If this means the portion of the OCL software that is not part of the workunits, then installing it is automatic for Nvidia GPUs if you get the driver directly from Nvidia, rather than from some other source that may modify it before passing it along (Microsoft often does).
http://www.nvidia.com/Download/index.aspx?lang=en-us
(Some exceptions for GPUs so old that they don't support OCL.) | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
All of my recent Genefer workunits were described as using OCLcuda rather than only CUDA or only OCL. Should I consider them as showing that both of my computers should be able to run the 3.30 OCL version?
You're already running OCL, and have nothing to worry about.
Forget about the plan_class names; they have specific naming requirements and can be confusing, specifically "OCLcuda" (That's the OCL app for Nvidia GPUs). If you have checked the "OpenCL" box in the preferences, you're getting the OCL app. If you checked the CUDA box, you're getting the CUDA app.
Someone asked how to install ocl.
There's nothing to install. The drivers for your Nvidia GPU -- the same ones that let you run CUDA apps -- include the drivers for OCL. In fact, you need LESS to run OCL than CUDA since there's no CUDA or cuFFT libraries required.
____________
My lucky number is 75898524288+1 | |
|
|
Replacing CUDA in favour of OCL (or whatever name you may use for it) seems to be the trend anyway too. POEM e.g. does ist the same way. I find less an less pure CUDA-Tasks (with low CPU-usage) within the world of BOINC.
After all considerations, giving up a core for solving numerous other problems seems very reasonable. | |
|
|
Replacing CUDA in favour of OCL (or whatever name you may use for it) seems to be the trend anyway too. POEM e.g. does ist the same way. I find less an less pure CUDA-Tasks (with low CPU-usage) within the world of BOINC.
After all considerations, giving up a core for solving numerous other problems seems very reasonable.
in this case, the combined OCL app doesn't use a cpu core - just as the CUDA application did.
____________
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
Replacing CUDA in favour of OCL (or whatever name you may use for it) seems to be the trend anyway too. POEM e.g. does ist the same way. I find less an less pure CUDA-Tasks (with low CPU-usage) within the world of BOINC.
After all considerations, giving up a core for solving numerous other problems seems very reasonable.
There might be some confusion here...
- We're not really replacing anything. Both OCL and CUDA have both been available for a year or two, and users could select whichever they wanted to run. What I'm planning on doing is removing CUDA because, at this point, it appears to be inferior in every way to the OCL version of the same program. It used to be that CUDA was better for some systems and some situations. No longer.
- OCL does NOT use a full core, at least as of the upcoming 3.3.0. It behaves just like the CUDA version of the program -- only faster -- and able to go to much higher b values -- and is also able to run on ATI/AMD and (theoretically) integrated GPUs.
____________
My lucky number is 75898524288+1 | |
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 496 ID: 284516 Credit: 988,009,508 RAC: 1,524,858
                         
|
I am going to speak anecdotally here for a moment. I will also preface this by stating that I may have an unstable graphics card even though none of the traditional graphics benchmarks or games have any issue running. If you look at my profile you can see that I'll have a few units with errors from GFN-17MEGA, GFN-18 and GFN-19.
Running the OCL app for GFN-21 and GFN-22 causes my system to stutter so badly it becomes unusable. After a while, anywhere from a few minutes to a few hours, a BSOD will happen.
Today I decided to give the CUDA version of GFN-21 a go to see what would happen. As of this post it has been running for 25 minutes without the tiniest indication that anything is even happening as far as system usability and stability are concerned. It's running fantastically. I will, of course, have to see if it returns an error or not in about 60 hours.
This may be a reason for keeping CUDA around, but if the new OCL acts like the current CUDA then I have no objections.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*9 + 8*3 + 10*1 + 11*3 = 150
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I am going to speak anecdotally here for a moment. I will also preface this by stating that I may have an unstable graphics card even though none of the traditional graphics benchmarks or games have any issue running. If you look at my profile you can see that I'll have a few units with errors from GFN-17MEGA, GFN-18 and GFN-19.
Running the OCL app for GFN-21 and GFN-22 causes my system to stutter so badly it becomes unusable. After a while, anywhere from a few minutes to a few hours, a BSOD will happen.
Today I decided to give the CUDA version of GFN-21 a go to see what would happen. As of this post it has been running for 25 minutes without the tiniest indication that anything is even happening as far as system usability and stability are concerned. It's running fantastically. I will, of course, have to see if it returns an error or not in about 60 hours.
This may be a reason for keeping CUDA around, but if the new OCL acts like the current CUDA then I have no objections.
Kieth, if screen lag is indeed a problem with OCL, then yours is the first response that's potentially useful to me. This is the first I've heard of anyone complaining about screen lag with OCL. Screen lag is common with CUDA, which is why we have a block size adjustment which lets you trade off performance for reduced screen lag.
There's no corresponding adjustment for OCL because there's been few if any complaints about it, and I'm not even sure if such an adjustment is possible with OCL. Because of the lack, or at least rarity, of such complaints, I'm wondering if the usability problems you're seeing are related to the other problems you're having with your GPU. It could be that there's an underlying problem causing both symptoms.
____________
My lucky number is 75898524288+1 | |
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 496 ID: 284516 Credit: 988,009,508 RAC: 1,524,858
                         
|
Kieth, if screen lag is indeed a problem with OCL, then yours is the first response that's potentially useful to me. This is the first I've heard of anyone complaining about screen lag with OCL. Screen lag is common with CUDA, which is why we have a block size adjustment which lets you trade off performance for reduced screen lag.
There's no corresponding adjustment for OCL because there's been few if any complaints about it, and I'm not even sure if such an adjustment is possible with OCL. Because of the lack, or at least rarity, of such complaints, I'm wondering if the usability problems you're seeing are related to the other problems you're having with your GPU. It could be that there's an underlying problem causing both symptoms.
Thanks for the reply!
It is definitely not out of the realm of possibility that I have issues.
GFN-15 through 17LOW gives no screen lag and no errors.
GFN-17MEGA through 19 gives no screen lag but the odd error.
GFN-20 gives slight lag and no errors.
GFN-21 and 22 gives painful screen lag and BSODs to the point I have to abort the units.
I would assume if there were a hardware issue I would see errors on all GFN... But maybe not. Could it be that the larger units are more hardware intensive which would expose an error that smaller units, games and benchmarks would not expose?
I'll run the GFN-21 CUDA until it either errors or completes successfully. If it completes successfully I will try a GFN-22 CUDA. If it doesn't then we can disregard all this.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*9 + 8*3 + 10*1 + 11*3 = 150
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I would assume if there were a hardware issue I would see errors on all GFN... But maybe not.
Not true. The larger numbers are much tougher on the hardware. More memory is being used, and the GPU "kernels" run for much longer periods of time, which means the GPU is running more before getting a break. (This is also why you see more lag on higher Ns.)
Could it be that the larger units are more hardware intensive which would expose an error that smaller units, games and benchmarks would not expose?
Absolutely.
The BSOD is something to be concerned about, however. That shouldn't be happening, period. Something is causing that, whether it's bad hardware, some installed software or drivers, malware, or whatever. Fix whatever that is, and the other symptoms might go away too.
Pay attention to the BOSD messaging -- it might be telling you what the culprit is.
____________
My lucky number is 75898524288+1 | |
|
|
I am going to speak anecdotally here for a moment. I will also preface this by stating that I may have an unstable graphics card even though none of the traditional graphics benchmarks or games have any issue running. If you look at my profile you can see that I'll have a few units with errors from GFN-17MEGA, GFN-18 and GFN-19.
Running the OCL app for GFN-21 and GFN-22 causes my system to stutter so badly it becomes unusable. After a while, anywhere from a few minutes to a few hours, a BSOD will happen.
Today I decided to give the CUDA version of GFN-21 a go to see what would happen. As of this post it has been running for 25 minutes without the tiniest indication that anything is even happening as far as system usability and stability are concerned. It's running fantastically. I will, of course, have to see if it returns an error or not in about 60 hours.
This may be a reason for keeping CUDA around, but if the new OCL acts like the current CUDA then I have no objections.
Kieth, if screen lag is indeed a problem with OCL, then yours is the first response that's potentially useful to me. This is the first I've heard of anyone complaining about screen lag with OCL. Screen lag is common with CUDA, which is why we have a block size adjustment which lets you trade off performance for reduced screen lag.
There's no corresponding adjustment for OCL because there's been few if any complaints about it, and I'm not even sure if such an adjustment is possible with OCL. Because of the lack, or at least rarity, of such complaints, I'm wondering if the usability problems you're seeing are related to the other problems you're having with your GPU. It could be that there's an underlying problem causing both symptoms.
This is not a Problem for me, so i never mentioned it, but Gfn 20-22 has some Screen lag on my System too.
It goes to the extend that i'm unable to use the Browser if a gpu unit is running.
Since i usually suspend boinc when my PC is in use i have no Problem with it.
I'm not sure if the lag did also occure with the seperate apps (i'm currently using the combined app)
____________
| |
|
Dave  Send message
Joined: 13 Feb 12 Posts: 3028 ID: 130544 Credit: 2,027,416,501 RAC: 791,740
                      
|
If you want a browser use your phone/tablet :). | |
|
|
I shall have to drop BOINC, I simply can't afford yet more equipment, Sorry and Bye.
____________
| |
|
Yves GallotVolunteer developer Project scientist Send message
Joined: 19 Aug 12 Posts: 702 ID: 164101 Credit: 305,166,630 RAC: 523

|
I shall have to drop BOINC, I simply can't afford yet more equipment, Sorry and Bye.
??? Why?
A Toulouse, on ne chasse pas les ours ;-)
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I shall have to drop BOINC, I simply can't afford yet more equipment, Sorry and Bye.
Since you posted this in a thread about shutting off the GeneferCUDA app, I'll assume that's related to your statement.
If so, that's exactly the purpose of this thread. I want to find out if anyone would be inconvenienced if the CUDA app goes away.
Please tell me why this would make you need to buy more equipment? As far as I know, anyone who is currently running GeneferCUDA can also run GeneferOCL, so no new equipment should be needed, and you will also see an improvement in speed.
P.S. Parrots also like to chew through wires with high voltage inside -- and they're much better at it than cats!
____________
My lucky number is 75898524288+1 | |
|
|
I read the announce of the end of CUDA as a warning that old type NVIDIA cards would be incapable of running the new system. I already have four NVIDIA and one AMD that get no work.
Merci @ Yves Gallot et Michael Goetz pour vos réponses, je laisse ma machine fait son travail dans ce cas.
P.S.
Et Yves, si tu veux être une membre d'un équipe, je suis honorais si tu me joindre, je suis de Béziers, ma belle sœur et mes nièces sont à Toulouse. | |
|
|
@Keith
GFN-15 through 17LOW gives no screen lag and no errors.
GFN-17MEGA through 19 gives no screen lag but the odd error.
GFN-20 gives slight lag and no errors.
GFN-21 and 22 gives painful screen lag and BSODs to the point I have to abort the units.
This is my experience also. As soon as the WU expands it's memory requirement and leaves GPU dedicated RAM to use a pool of shared system RAM is when the BSODs start occurring on all 3 of my Dell Precision m6xxx series workstations. 6300, 6400 and 6500 all get BSoD in GFN-21/22 along with massive stuttering. It doesn't matter if it's OCL or CUDA.
I do not know where the issue is exactly but timing differences between dedicated RAM and shared on Dell motherboards and Windows 7 always gave me trouble so I dropped back to 15, 17LOW, 17MEGA and 19 only. I'm not sure what other machines with nVidia cards have these issues but my ATI card on the HP 8560p has no BSOD but just hogged up an entire CPU core and that I couldn't tolerate.
It doesn't appear to be heat related as I use MSI afterburner and keep the GPU's under 55. It's possible the problem is in heating of the system RAM but that is kept under 45 with Speedfan and conservative fan triggers that force fans up to max at lower levels than Dell's BIOS settings.
---
BTW, @Michael Goetz, I checked my project settings and my older machines have been using OpenCL on 17 LOW and MEGA so ignore my earlier question. | |
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 496 ID: 284516 Credit: 988,009,508 RAC: 1,524,858
                         
|
This is my experience also. As soon as the WU expands it's memory requirement and leaves GPU dedicated RAM to use a pool of shared system RAM is when the BSODs start occurring on all 3 of my Dell Precision m6xxx series workstations. 6300, 6400 and 6500 all get BSoD in GFN-21/22 along with massive stuttering. It doesn't matter if it's OCL or CUDA.
I do not know where the issue is exactly but timing differences between dedicated RAM and shared on Dell motherboards and Windows 7 always gave me trouble so I dropped back to 15, 17LOW, 17MEGA and 19 only. I'm not sure what other machines with nVidia cards have these issues but my ATI card on the HP 8560p has no BSOD but just hogged up an entire CPU core and that I couldn't tolerate.
It doesn't appear to be heat related as I use MSI afterburner and keep the GPU's under 55. It's possible the problem is in heating of the system RAM but that is kept under 45 with Speedfan and conservative fan triggers that force fans up to max at lower levels than Dell's BIOS settings.
---
BTW, @Michael Goetz, I checked my project settings and my older machines have been using OpenCL on 17 LOW and MEGA so ignore my earlier question.
Since you are having this in CUDA as well as OCL then we likely aren't having the same experience as CUDA runs perfectly for me in both GFN-21 AND GFN-22.
I should update on my previous posting. As per Michael's suggestion I did a system cleanup and update back on Saturday. I uninstalled all programs I wasn't using, did Windows Updates, and updated all of my device drivers.
Since then I have done a GFN-21 CUDA unit which validated and had absolutely no screen lag even when watching Youtube or Netflix. I then ran a GFN-21 OCL and it also validated, but it still had screen lag, but unlike before, it was manageable and not overly disruptive. So a definite improvement was had.
I am currently running a GFN-22 CUDA and I am having much the same experience as the GFN-21 CUDA. A GFN-22 OCL is up next to see what happens.
I think what I'm asking about here is if the CUDA can be kept for a brief period after the new GFN app is launched just to see if the 3.3.0 app works like the current 3.2.9 app for me or if it runs like the CUDA app for me.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*9 + 8*3 + 10*1 + 11*3 = 150
| |
|
Yves GallotVolunteer developer Project scientist Send message
Joined: 19 Aug 12 Posts: 702 ID: 164101 Credit: 305,166,630 RAC: 523

|
As soon as the WU expands it's memory requirement and leaves GPU dedicated RAM to use a pool of shared system RAM is when the BSODs start occurring on all 3 of my Dell Precision m6xxx series workstations. 6300, 6400 and 6500 all get BSoD in GFN-21/22 along with massive stuttering. It doesn't matter if it's OCL or CUDA.
Memory allocation is "small":
GFN-20/OCL uses ~ 60 MB GPU-mem, GFN-21/OCL ~ 80 MB, GFN-22/OCL ~ 130 MB and
GFN-20/OCL4 ~100 MB, GFN-21/OCL4 ~160 MB, GFN-22/OCL4 ~280 MB.
I think that if a GPU is not able to allocate these sizes in dedicated RAM, then it can't check a candidate in a resonnable amount of time... !?
| |
|
|
Hi !
Just tried OCL app (GFN16) instead of CUDA with my Nvidia GT430 (no oc), compute capability = 2.1..
It's very fast !! 14min to get... an error while computing.
On Boinc's events, it's returning the results and then say that if I get errors repeatly I should reset the project.
Any advice ?
For now, I stay on CUDA.
Thanks. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
Hi !
Just tried OCL app (GFN16) instead of CUDA with my Nvidia GT430 (no oc), compute capability = 2.1..
It's very fast !! 14min to get... an error while computing.
On Boinc's events, it's returning the results and then say that if I get errors repeatly I should reset the project.
Any advice ?
For now, I stay on CUDA.
Thanks.
I don't see any GeneferCUDA tasks on that machine. The only GPU task I can see is a sieve. You have run the large n=21 or n=22 GFN tasks on your GT 430?
(Regardless of your answer, the OCL program *should* have worked. I do want to discover why it didn't. But it would help to know if you've run the GFN CUDA apps.)
____________
My lucky number is 75898524288+1 | |
|
|
I remember now, I switched to GFN CPU, I leave Sieve as CUDA's app.
Well, should I test first if GFN CUDA's working before testing OCL GFN app ?
I did had a previous GFN problem but I changed both system and hardware (but not the graphic card).
Before trying to fix something, do you think that if I run GFNcpu app with an Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, it's better than an old (CUDA or OCL) GPU GT430 ?
I don't remember if I try both :/. Maybe should I continue with GFNcpu :) | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I remember now, I switched to GFN CPU, I leave Sieve as CUDA's app.
Well, should I test first if GFN CUDA's working before testing OCL GFN app ?
Nooooooooooo!
My old GTX 640 took about 12 days to do n=22 tasks. Without looking up the specs, I'm guessing the GT 430 is at least 4 times slower than the GTX 460, so you're looking at close to 2 months to run a single n=22 task.
I did had a previous GFN problem but I changed both system and hardware (but not the graphic card).
That seems to be unrelated.
Before trying to fix something, do you think that if I run GFNcpu app with an Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, it's better than an old (CUDA or OCL) GPU GT430 ?
You've asked a really good question here. Suggesting that the GT 430 is getting a bit long in the tooth would be insulting long teeth. It's fairly old, and even when brand new was at the bargain-basement end of Nvidia's product line.
Your i6-4770 Haswell, by comparison, is only one generation removed from the bleeding edge Intel CPUs. Set BOINC to run 50% of the CPUs, effectively turning off hyperthreading, and you'll be running GFN tasks fairly quickly. I'd say away from GFN-22's, because they're so long. They will probably take about 3 weeks or more on your CPU. The n=21 tasks would be about 4 times shorter.
There's 9 different sizes of GFN tasks to choose from, but only some of them (22, 21, and for at least a few more tasks, 20 and 19) will be able to use the full abilities of your CPU. The other N's have to use slower transforms.
I don't remember if I try both :/. Maybe should I continue with GFNcpu :)[/quote]
____________
My lucky number is 75898524288+1 | |
|
|
You've asked a really good question here. Suggesting that the GT 430 is getting a bit long in the tooth would be insulting long teeth. It's fairly old, and even when brand new was at the bargain-basement end of Nvidia's product line.
OK I think that's why I turned off GPU for GFN.
[...] effectively turning off hyperthreading, and you'll be running GFN tasks fairly quickly. I'd say away from GFN-22's, because they're so long.
50% to get some CPU for myself :).
I should turn off hyperthreading ? What benefits ?
They will probably take about 3 weeks or more on your CPU. The n=21 tasks would be about 4 times shorter.
Well, my cumputer don't work 24/7. If the deadline is OK, I can crunch long tasks, but if the deadline need full day on it, I won't do it.
There's 9 different sizes of GFN tasks to choose from, but only some of them (22, 21, and for at least a few more tasks, 20 and 19) will be able to use the full abilities of your CPU. The other N's have to use slower transforms.
The last (22) is very long indeed. I think all others are OK.
I keep my old GPU for easiest tasks (Sieve or other projects) then. | |
|
RafaelVolunteer tester
 Send message
Joined: 22 Oct 14 Posts: 905 ID: 370496 Credit: 459,496,650 RAC: 148,364
                   
|
I keep my old GPU for easiest tasks (Sieve or other projects) then.
http://i.imgur.com/Z4pcrnT.jpg
Joke aside, it's a way to help the genefer research if you can't actually run the software (and even if you could, it's still a more efficient way). The fact that there aren't fixed deadlines and that you can adjust the speed of the software to not interfere with your computer on such weak GPU are also a bonus. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I should turn off hyperthreading ? What benefits ?
For LLR and GFN tasks, turning off hyperthreading obviously reduces the number of tasks running by 50%, but the tasks will run slightly better than twice as fast. Net result is more tasks get done over a fixed period of time.
The type of calculation being done does not benefit from hyperthreading, but the increased cache and memory contention caused by running twice as many tasks will hurt your overall calculation speed. So it's better to run GFN without hyperthreading.
Over in the challenge thread, a guy with an i7-4790K "Devil's Canyon" Haswell CPU is seeing about 12 hour run times on SR5 tasks. He's using hyperthreading.
My CPU is an almost identical i5-4670K Haswell CPU. The differences are that the i5 has no hyperthreading, has a smaller cache and runs a few hundred MHz slower than the i7-4790K. In other words, my CPU is a slower version of his CPU, except mine doesn't have hyperthreading. Mine completes 4 SR5 tasks in 4 to 5 hours; his completes 8 SR5 tasks in 12 hours. The hyperthreading is causing his faster CPU to take longer to do 8 tasks than my slower CPU takes to do 8 tasks.
The SR5 tasks use LLR, but Genefer should perform similarly.
____________
My lucky number is 75898524288+1 | |
|
|
Well, thanks for those great explanations, I have some CPU time for GFN, for example : GFN20 (3.09) 32 hours to complete. I'll try without HT and see results.
And be sure that my old GT 430 will be on Sieve tasks, as it's my second graphic card Boinc dedicated. | |
|
|
Just tried OCL app (GFN16) instead of CUDA with my Nvidia GT430 (no oc), compute capability = 2.1..
It's very fast !! 14min to get... an error while computing.
I do want to discover why it didn't.
The most likely reason is that the CL_DEVICE_MAX_WORK_GROUP_SIZE is < 256 for that device. That might be a property of the device or the driver, or a combination of both. If you're able to compile and run the clGetDeviceInfo code from the OpenCL SDK this will tell you what the value of that property is.
What would also be interesting would be to try out the new genefer 3.3.0 app. Download the linux binary from http://www.primegrid.com/forum_thread.php?id=6669 and test both the OCL3 and OCL4 transforms:
./geneferocl_linux64 -r -x ocl3
./geneferocl_linux64 -r -x ocl4
Cheers
- Iain
____________
Twitter: IainBethune
Proud member of team "Aggie The Pew". Go Aggie!
3073428256125*2^1290000-1 is Prime! | |
|
|
OK but I get "Seg fault" as a results with those two commands.
P.S. : it seems that WU now running GFN20cpu without HT are estimated 33hours (same as HT enabled). | |
|
|
Reporting results here, as expected the two cpuGFN20 without HT completed in 31.5 hours and 32.4 hours.
I turn HT on again.
I found another topic "LLR and HT", and it seems that it's only on Windows based system that makes a difference. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
I found another topic "LLR and HT", and it seems that it's only on Windows based system that makes a difference.
Not true. HT or not HT is something built into the CPU itself and the operating system doesn't affect it very much. It certainly affects both Linux and Mac systems.
Anyway, the HT discussion is OFF TOPIC in this thread, so please take any further discussion about hyperthreading to an appropriate topic/thread, or create a new one. Further HT posts in this thread will be hidden.
GETTING BACK ON TOPIC... Is there anyone who actually HAS been running the GFN n=21 or n=22 GeneferCUDA apps who is also UNABLE to run the GFN n=21 or n=2 GeneferOCL apps? That's the specific concern here.
If there is, I want to understand why it is that you can run those CUDA apps but not the OCL apps.
The new 3.3.0 apps will go live fairly soon (we actually have a deadline coming up on GFN-16 where a new app must be installed before the current app stops working), and I'll be turning off the CUDA apps at some point after that.
Please respond here ONLY if you can run the current GFN n=21 or n=22 CUDA apps but can not run the GFN n=21 or n=22 OCL apps.
I think I overlooked a post by Malcolm Beeson earlier:
I read the announce of the end of CUDA as a warning that old type NVIDIA cards would be incapable of running the new system. I already have four NVIDIA and one AMD that get no work.
I'm not sure why you would think that. As far as I know, any GPU that currently can run GeneferCUDA can also run GeneferOCL. The only difference will be that the GPU will be faster when running GeneferOCL.
____________
My lucky number is 75898524288+1 | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
Upon reflection, I want to hear about the following three (maybe four) things, IF AND ONLY IF they apply to you. Any other posts will probably be hidden. I want to be able to see if anyone actually will be affected, so from now on I'm keeping this topic tightly focused on this narrow issue. Other posts will be hidden.
I want to know if...
1) You CAN run GeneferCUDA on N=21 or N=22 but CAN NOT run GeneferOCL on N=21 or N=22.
2) GeneferCUDA runs FASTER on N=21 or N=22 than GeneferOCL.
3) Screen lag is NOTICEABLY AND SIGNIFICANTLY WORSE with GeneferCOCL on N=21 or N=22 than with GeneferCUDA.
4) Any other valid reason why you want to use GeneferCUDA rather than GeneferOCL. I don't think there are any other reasons, but you may have one that I didn't think of. If it's off topic like most of the previous posts, your post will be hidden.
* Posts about GFN 15 through 20 will be hidden.
* Posts about ATI/AMD GPUs will be hidden.
* Posts about CPU apps will be hidden.
Please let's keep focused on this one question. Thank you!
____________
My lucky number is 75898524288+1 | |
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 496 ID: 284516 Credit: 988,009,508 RAC: 1,524,858
                         
|
1) You CAN run GeneferCUDA on N=21 or N=22 but CAN NOT run GeneferOCL on N=21 or N=22.
2) GeneferCUDA runs FASTER on N=21 or N=22 than GeneferOCL.
3) Screen lag is NOTICEABLY AND SIGNIFICANTLY WORSE with GeneferCOCL on N=21 or N=22 than with GeneferCUDA.
4) Any other valid reason why you want to use GeneferCUDA rather than GeneferOCL. I don't think there are any other reasons, but you may have one that I didn't think of. If it's off topic like most of the previous posts, your post will be hidden.
1) No issue with the ability to run OCL or CUDA here.
2) OCL definitely returns results faster. N=21 was 14 hours faster and N=22 is looking to be 48 hours faster on a per unit basis using OCL over CUDA
3) Screen lag with OCL N=21 is present, but manageable.
Screen lag with N=22 is painful. It is borderline unworkable. Anything more complex than basic web browsing and I have to stop the task.
Screen lag with CUDA on either N=21 or N=22 is not present at all.
If I didn't use this system as my primary daily computing device I wouldn't even care about the screen lag.
4) No other reasons than the screen lag while using my system for wanting to use CUDA over OCL. And it is entirely possible that with the improvements made to the new OCL app that I won't see any screen lag going forward.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*9 + 8*3 + 10*1 + 11*3 = 150
| |
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 496 ID: 284516 Credit: 988,009,508 RAC: 1,524,858
                         
|
So I'm finally running a GFN-21 using the new OCL app.
Kudos on an app well done! Absolutely no screen lag what-so-ever now. No more need for CUDA at all as OCL is behaving perfectly.
I retract my previous defense of the CUDA app.
Thanks!
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*9 + 8*3 + 10*1 + 11*3 = 150
| |
|
|
As GeneferCUDA apps are about to be removed it becomes crucial for me to be able to run the GeneferOCL 3.3.0. apps. Currently they are all failing.
“Output file …. For task … absent”
I put a post in the Problem section.
Any assistance shall be greatly appreciated.
Yair | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
As GeneferCUDA apps are about to be removed it becomes crucial for me to be able to run the GeneferOCL 3.3.0. apps. Currently they are all failing.
“Output file …. For task … absent”
I put a post in the Problem section.
Any assistance shall be greatly appreciated.
Yair
Your video driver is 364, right? I recommend installing an older driver because that one is known to be problematic. OCL not working is the lesser of the two problems I've heard of; supposedly it has caused GPU damage.
____________
My lucky number is 75898524288+1 | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
We will be turning off the CUDA apps in the next couple of days. The timing of this decision is due to the Nvidia driver bug -- we can't tell which CUDA tasks might be affected by the bug and which ones aren't.
This is the final notice -- it's time now to switch from CUDA to OCL. Please go to the preferences page and deselect CUDA, then select the OpenCL box that is immediately above the CUDA box. If you do that, you'll find that your GPU is likely processing tasks faster than before. In some cases, a lot faster. If you don't, you'll soon find that your GPU isn't getting any tasks.
This change only affects GFN-21 and GFN-22 (aka GFN-WR).
____________
My lucky number is 75898524288+1 | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13780 ID: 53948 Credit: 343,968,988 RAC: 10,814
                              
|
The GeneferCUDA apps are now deprecated.
The Genefer CUDA apps are no longer being sent out, and you can no longer select them on the PrimeGrid preferences page. If for some reason you still had CUDA selected for GFN-21 or GFN-22 you will need to select Nvidia OpenCL instead.
If you've got Genefer CUDA apps that are currently running, you may complete them if you wish. They will be accepted when returned to the server.
Please note that this does not affect ATI/AMD GPUs. It does not affect GFN-15 through GFN-20. It does not affect PPS-Sieve. It does not affect CPU apps.
____________
My lucky number is 75898524288+1 | |
|
Message boards :
Generalized Fermat Prime Search :
Deprecating GeneferCUDA |