Forum > GPU crunching
Driver, application and VRAM requirement?
Josef W. Segur:
The CPU fallback in the CUDA apps happens without BOINC knowing about it, so it assumes the CUDA task it started is only using a small fraction of a CPU and will start a CPU task also. The CUDA task is running at a higher priority than the CPU task, so runs mostly uninterrupted using the minimal default set of CPU code. The task started for the CPU will probably run quite slowly since it will get much less CPU time. So not only would the task started for CUDA be running slowly on CPU, a CPU task would also be running slowly; as Raistmer said, the worst possible way to do work.
Raistmer wrote:
--- Quote ---Another way is to fallback to older CUDA DLLs (like 2.2 or even older) they have slower cuFFT but require less memory. That way will be still much better than CPU fallback mode.
--- End quote ---
I think that is the only way you'll be able to crunch with 256 MB VRAM.
Joe
Richard Haselgrove:
It'll be a bit difficult to work out what's happening until the outage is over, and we can see both CPU and Elapsed times reported on the website: I think BOINC does record actual CPU usage, even on a nominal GPU-allocated task.
At the moment, I'm getting confused signals. It looks as if the optimized CUDA MBnokill you started with has broken CPU fallback code, and just errors on low memory. From what you've said, the v6.08 CPU fallback mode is kicking in as designed, and at least generating a result - but at the lowest possible speed. The CPU code in that build has few, if any, of the optimisations present in even the stock v6.03 CPU application, let alone the additional ~2x speedup available with AK_v8b. Why NVidia incorporated such a crappy CPU codebase, I'll never know.
But your later observations don't bear that out. More heat from the GPU? That implies work - so what's it doing? (Unless, just possibly, merely starting the app kicks up a fequency shift, from idle to active - that sort of thing might be expected in a notebook). And if the CPU is doing the bulk of the heavy lifting for the nominal 'GPU' app, you'd expect that the elapsed timings for CPU tasks (I'm presuming those are what you're reading, from BOINC Manager) would increase significantly, even if CPU time should remain constant. Unless, again, the higher-priority GPU app is triggering a frequency increase in the CPU, from idle to performance. That's been a nasty gotcha for Linux users, which took a long time to track down the first time we came across it - presenting problem was that the Linux app was about half as efficient as the equivalent Windows app, which didn't make sense.
It would certainly be worth running GPU-Z in the background, and watching in particular what happens to GPU speed and utilisation as a new task starts up (from scratch, obviously, rather than replacing an existing running task). It might also be worth having a look at what the power management settings are doing for the system as a whole. If the notebook is high enough spec to have a Quadro as standard, then it's probably got some good power control stuff as well. Check both the BIOS, and for any Vista power extensions. Just for experimentation and understanding what's going on, it would be good to eliminate any variability from frequency shifting you can, while you test everything else. And you might even be able to allocate more RAM to the GPU in BIOS.
Miep:
--- Quote from: Josef W. Segur on 21 Jul 2010, 11:20:10 pm ---The CPU fallback in the CUDA apps happens without BOINC knowing about it, so it assumes the CUDA task it started is only using a small fraction of a CPU and will start a CPU task also. The CUDA task is running at a higher priority than the CPU task, so runs mostly uninterrupted using the minimal default set of CPU code. The task started for the CPU will probably run quite slowly since it will get much less CPU time. So not only would the task started for CUDA be running slowly on CPU, a CPU task would also be running slowly; as Raistmer said, the worst possible way to do work.
--- End quote ---
I hate it when I manage to kill my own post while writing... OK let's see...
You were right , of course ;)
GPU memory shifts from 19 to 136 used and after a few secs down to 49 and stays there. Core clock, memory clock and shader clock all go up and stay up. (whatever that exactly is...)
I suppose Richard is right - enough to shift (and heat up) not enough to run.
We are talking 6.08 stock right now, as I understood it, optimized has higher memory requirements? So, if I can't get stock to run, no point in vieing for opt.
--- Quote ---Raistmer wrote:
--- Quote ---Another way is to fallback to older CUDA DLLs (like 2.2 or even older) they have slower cuFFT but require less memory. That way will be still much better than CPU fallback mode.
--- End quote ---
I think that is the only way you'll be able to crunch with 256 MB VRAM.
Joe
--- End quote ---
Ah, I think you laid the finger in the wound.
When I downgraded the driver last week I was far to stressed to pay attention to details. I wrongly assumed the libs would follow suit. However:
--- Code: --- 22/07/2010 09:47:08 NVIDIA GPU 0: Quadro FX 570M (driver version 19562, CUDA version 3000, compute capability 1.1, 256MB, 61 GFLOPS peak)
--- End code ---
So Cuda 3.0 dll lib?
Well guess I have to remove a couple of files then to get back to 2.2. So, what needs removing/replacing? I doubt I can find all relevant files on my own...
Thanks a lot.
Richard Haselgrove:
Don't worry about the 'version 3000' from BOINC - that's just showing the maximum version you could use with that driver.
You can use lower versions, just by changing the two DLLs in the boinc\projects\sah directory.
Attaching, for simplicity, the 2.2 and 2.1 versions - straight file replace, no rename. Stop BOINC first, obviously, and try: 2.2 first, 2.1 if that fails.
Let me know when you've downloaded the files, and I'll remove the attachment - save server space.
Edit - attachments removed, served their purpose.
Miep:
Ta.
Ack. That was 2.2 in there... Ok trying 2.1
As the GPU is on a 4 min wait for inactivity, no results expected before tomorrow.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version