Forum > GPU crunching

Driver, application and VRAM requirement?

<< < (5/13) > >>

Claggy:
Just the CPU fallback code, and it was so so slow,

Claggy

Miep:
I told you i was running, what I assume to be the bare minimum...
When CUDA came out last year (?) I looked my GPU up and it stated it could do it. Required me to figure out that I needed to upgrade the driver though. It was crunching happily then - you can just about see the increased throughput from 8/09 to 2/10 on the boincstats graphs... but unless I find I have a non kompressed backup of my data partition from that period I can't check the respective driver/dll/client_stat. And that was with aero and 32bit colours - I've disabled that atm.
I was running stock then, so whatever dll you get/got delieverd with 6.08. (well last august...)
It was just the reduced reported RAM from that @!£$ (sorry) 197 driver update that took the GPU out of action for SETI.
I'll see if I can find a backup on Monday, would answer a few questions...

Raistmer:
hm.... could it be not only driver update but boinc itself update too?
Early BOINC versions didn't handle GPU but didn't load it also.
Currently BOINC is gpu-aware, but this could require some gpu memory too. At least what needed is context creation. How much memory driver assosiated with context by default?.... IMO it's worth to check GPU memory usage with BOINC doing only CPU tasks and w/o BOINC at all too.
Also, maybe try to go to older instead of newer BOINC versions.

Richard Haselgrove:
I don't see how the BOINC version can make any difference at all. You know the code better than me, but surely there are only two places where BOINC interacts directly with any GPU:

1) At startup, when it queries the device capabilities - calling the APIs in the driver's DLLs, and populating the COPROCS structure. But that would be held in CPU / system RAM - I don't see why changes to this detection phase should tie up any extra VRAM.

2) At application launch - every project science app has BOINC code in it, from the API libraries, to allow communication and control with the core client. But that's built into the application itself - AFAIK, no application picks up any new library code from a later BOINC installation.

The only possibility I can see is that Carola might have been using an even older NVidia driver, possibly Notebook Release 186 WHQL 186.81 or even Quadro FX Release 186 for Notebooks 186.03, which would rule out CUDA 2.3 but might allow 2.2 to run.

Miep:
@Raistmer context creation? sorry you lost me - you want me to check GPU usage under different scenarios, to see what influences the components have? ok, I'll try.
btw ther's a 'H' missing in your 'IMO' ;)

You made me remember that I have a Boinc directory backup from May. not old enough to check what the GPU was running with or any errors, but stdout(.old) should go back far enough to see what boinc version and dribver Iwas running:

Boinc 6.10.18 and Nvidia 195.62. (while still showing 6.08 tasks) in february
upgraded to 6.10.36, still running 6.08 - but of course with no idea whther it had not fallen back tp the CPU already.
and then with the upgrade to 197.16 and the reported memory of 242 it didn't get more 6.08 tasks - though it took me a while to realize that that was the cause...
dll are from 11/09 and look like 2.1 - no 2.2 in the details tab.
I tend to run latest recommended and newest driver...

I'll have a look for backups on Monday, but I'don't think I ever upgraded to 2.2 dll - if that had to be done manually almost certainly not.
The 2.2 I found in place are most likely from the .36 installer...

Navigation

[0] Message Index

[#] Next page

[*] Previous page