DiabloMiner uses about one 50% of CPU on my system (distributed among 2 cores). I could have sworn that it used almost no CPU (1-2% max) in older versions, but I'm not really sure if I should report this as a bug or not. So, is it normal, or am I correct in remembering that GPU miner should not use more than 1-2% of CPU while mining?

Link: Possibly related question.

3 Answers 3


I'm surprised you just didn't ask me directly.

It sounds a lot like you're suffering from one of two CPU use bugs in the driver. Catalyst 11.7 through 11.11 (using any SDK) use 100% CPU time on one or more cores because of a faulty sleep, and SDK 2.2 and 2.3 (using any Catalyst) also have the same exact issue.

However, Windows has a third variation of the bug, if you set -f too low (ie, kernel work size or kernel execution time exceeds a predefined amount), it can also trigger Windows into stating the CPU is being used 100%, however this does not seem to be a driver bug and is a bug in Windows itself.

Edit: My answer was strictly for AMD hardware. If you're on Nvidia, Nvidia is aware of the bug (it happens on any OpenCL app), but they have not yet fixed it.


It almost certainly is related to the question you linked and it almost certainly has the same answer I'm sad to say. There is a lot of this going around and no one is really certain what exactly is causing it.

There have been reports that ATI's 11-7_vista64_win7_64_dd_ccc_ocl drivers often bring the problem about, and reverting back to an 11-6 version seems to fix it. Not sure if it will work for you or if it even applies to your situation but it's worth a shot.

  • Curiously, I'm experiencing the same on NVIDIA card (yeah, not seriously into mining), so I guess the problem is in OpenCL instead of in manufacturer's drivers themselves.
    – Domchi
    Sep 1, 2011 at 8:47

One of your CPUs is spin-waiting for the GPU to finish work units. Generally, GPU drivers have two options to wait for the hardware: either suspend the process until an interrupt is generated, or poll the GPU whether it is finished in a tight loop. It seems your driver is using the second approach and thus takes 100% CPU of one core.

The advantage of polling is that there is less latency than with interrupts, for example when doing real-time work on the GPU; but in case of a background process like mining which hardly requires CPU intervention, sleeping would be a better option.

It might be that ATI changed this in recent drivers. In CUDA this is an option when creating the compute context (SCHED_AUTO/SCHED_SPIN/SCHED_YIELD) to choose the waiting method, but alas, I know of no such option for OpenCL.

  • This makes sense. Is is possible to change this setting in either NVIDIA or ATI driver, or is this only the privilege of driver makers?
    – Domchi
    Sep 18, 2011 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.