Driver, application and VRAM requirement?

[Miep]

Logging shows no GPU memory takeup when Boinc starts or comes out of initial delay. Doesn't have decimals, though. When the GPU task starts it  goes from 19 to 89, 106,210 used and some 15 seconds later to 218.
V12nokill and 2.1 dll (are you sure they are 2.1 and not 2.0 Richard? They don't have a version number on the details tab.) boinc 6.10.58 nvidia driver 195.62

[Richard Haselgrove]

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

[Miep]

So I tried the 2.2 dll again - as previously with V12: it errors out. I let it through: this task for closer inspection, but I'd say it just tries to fall back to CPU and can't.

I can try higher dlls (if somebody tells me where to get them) but don't they need even more memory?

Any thoughts on whether to try to upgrade to newest driver?

[Richard Haselgrove]

So I tried the 2.2 dll again - as previously with V12: it errors out. I let it through: this task for closer inspection, but I'd say it just tries to fall back to CPU and can't.

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 can try higher dlls (if somebody tells me where to get them) but don't they need even more memory?

Any thoughts on whether to try to upgrade to newest driver?

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.

[Miep]

So I tried the 2.2 dll again - as previously with V12: it errors out. I let it through: this task for closer inspection, but I'd say it just tries to fall back to CPU and can't.

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.

And I thought we had established that 6.08 with 2.2 does CPU fallback...
But ok, I'll swap the 6.08 and the 2.2 back in. next one up is a shorty so not too painfull for fallback...

I can try higher dlls (if somebody tells me where to get them) but don't they need even more memory?

Any thoughts on whether to try to upgrade to newest driver?

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.

I'm not prepared to touch the BIOS while I need this machine.
197.16 was fine running what was there, just didn't get new tasks as per reduced reported memory. I think that might partly answer the question regarding Boinc checking GPU ram requirement.
I could maybe try removing app_info and look what boinc, the application and the server think about 6.08 with 2.1 and 2.2 respectively.

I'll probably have a go at the newest driver in an idle moment. I can always downgrade again.

Edit: forum doesn't seem to cope very well with multiple quotes, sorry.

[Miep]

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

[Raistmer]

AFAIK stock plan class cuda23 supplies 2.3 DLLs as well.

[Richard Haselgrove]

AFAIK stock plan class cuda23 supplies 2.3 DLLs as well.

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

[Frizz]

I recently got some WUs with Out Of Memory errors, like this one here:

http://setiathome.berkeley.edu/result.php?resultid=1666139183

I never had this before. Are the 512MB of my GT240 not enough any more?

[Raistmer]

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

[Miep]

Richard? Care to throw the 2.3 dll's my way? Not that I think they will work, but then I will haved tested that...
Yes I know, the v36 installer has them sonewhere, but I don't want to write over the current setup

Edit: nevermind, I realized I can just backup, install, extract the files and put the backup back in...

[Richard Haselgrove]

Richard? Care to throw the 2.3 dll's my way? Not that I think they will work, but then I will haved tested that...

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.

[Claggy]

Richard? Care to throw the 2.3 dll's my way? Not that I think they will work, but then I will haved tested that...
Yes I know, the v36 installer has them sonewhere, but I don't want to write over the current setup

Edit: nevermind, I realized I can just backup, install, extract the files and put the backup back in...

The 2.3 dll's are in downloads: Windows Setiathome apps

Claggy

[Miep]

The 2.3 dll's are in downloads: Windows Setiathome apps

Claggy

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.

[Richard Haselgrove]

Richard? Care to throw the 2.3 dll's my way? Not that I think they will work, but then I will haved tested that...
Yes I know, the v36 installer has them sonewhere, but I don't want to write over the current setup

I've put them all up on my public SkyDrive SETI@home stuff folder. I'll find 3.1 and add it when I've sorted myself out a bit. Later - v31.9 DLLs added to the same location - took them from Jason's public beta download, so blame him of they don't work.