@ Raistmer - I can't confirm that BOINC takes no CUDA memory - you and Jason have a better grip on the code. Heck, you're been compiling and releasing it practically since we dicovered VLAR together, with Jord's NB, back at the transition from v6.07 to v6.08 in January 2009. All I can say is that BOINC has no business in, and nothing to be gained by using, any of the GPU memory area. No science in BOINC! BOINC is management and control only. It needs to know about the GPU - memory, speed, capabilities etc. - but all its local storage surely goes in system RAM with the eqivalent knowledge about CPU capabilities.

@ Carola - no, I'm not sure what the exact designation of the antediluvian DLLs is. There's a set downloadable from the project fanout since about December 2008, which NVidia didn't see fit to label. The next set anybody noticed was definitely 2.2: Jason tested them, and they were better. Then came 2.3: I tested them, and they were better still. Certainly, nobody registered a switch from 2.0 to 2.1: my download archives don't have separate sets. When I get back home to a proper rig (tomorrow or Monday), I can do a proper search of the NVidia toolkit archives, extract the DLLs, and do some proper research: if there's anything between stock 'cuda' and 2.2 and stock 'cuda23', I'll send it over for testing.

But that stderr_txt shows you're using Raistmer's code - and I thought we'd established that the CPU fallback was broken on that build? The question would be whether you can get the STOCK v6.08 app into app_info, and run it with the 2.2 DLLs. That would give better results than Raistmer's app with 2.1 DLLs, and still have a working fallback if things go wrong.


I'm afraid both newer DLLs, and newer drivers, are likely to outface your limited memory - unless you can squeeze more RAM out of the BIOS.

So, swapped in 6.08 and 2.2dll over night. [url-=http://setiathome.berkeley.edu/result.php?resultid=1661917453]task[/url] CPU fallback as before. Can't comment on the runtime, nothing available for comparison. Times for the 2 CPU tasks went through the roof. well actually I think they are about 2x the previous average, consistent with CPU fallback grabbing one core and the two CPU tasks having to share the other.

Right, now I get it. The incresed speed of V12 is not primarily due to the application, but to the fact, that the installer supplies 2.2 or 2.3 dlls... Nice work

Certainly does, but also checks for driver version (>= 190.38, IIRC) and VRAM (384MB) before it'll issue @ cuda23.

It's just "-12" error. It was discussed many times look SETI main forums for details.
"out of memory" is "out of host not GPU memory" and don't ask why C++ runtime library says that on exception handling

Can do when I get home, but don't have a set here. Makes sense for you to have then in a package for local swapping in/out as you test, anyway.

Much easier, thanks. (of course 'warum einfach, wenns auch kompliziert geht' - why easy, when you can do it complicated)

I've upgraded to driver 258.96 and after sorting out the hiccups (had reverted to 32bit colours) it looks like base memory usage is unchanged and preliminary results suggest app is running fine.
Intrestingly max mem usage seems to be down to 201 from previous 218.